linux-kernel - Re: [PATCH v4 01/24] input: Add ff-memless-next module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2533450.JrQEqMHNCJ@sigyn>
Date:	Wed, 14 May 2014 21:40:05 +0200
From:	Michal Malý <madcatxster@...oid-pointer.net>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	jkosina@...e.cz, elias.vds@...il.com, anssi.hannula@....fi,
	simon@...gewell.org
Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wednesday 14 of May 2014 11:14:02 Dmitry Torokhov wrote:
> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> > +
> > +/** input_ff_create_mlnx() - Register a device within ff-memless-next and
> > + *                           the kernel force feedback system
> > + * @dev: Pointer to the struct input_dev associated with the device.
> > + * @data: Any device-specific data that shall be passed to the callback.
> > + *        function called by ff-memless-next when a force feedback action
> > + *        shall be performed.
> > + * @control_effect: Pointer to the callback function.
> > + * @update_date: Delay in milliseconds between two recalculations of
> > periodic + *               effects, ramp effects and envelopes. Note that
> > this value will + *               never be lower than (CONFIG_HZ / 1000)
> > + 1 regardless of the + *               value specified here. This is not
> > a "hard" rate limiter. + *               Userspace still can submit
> > effects at a rate faster than + *               this value.
> 
> The update rate change seems useful whether we use new ff implementation
> or enhance the old one but I would prefer having a separate call to
> control it.

OK, that should not be a problem. Please note that the plan is to use this 
value to do proper "hard" rate limiting in the future.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/