Re: [PATCH] input: evdev: Add a read() callback

["Henrik Rydberg" <rydberg@euromail.se>]

Hi Bill,

Some additional comments inline.

On Mon, Feb 21, 2011 at 08:18:50AM -0600, Bill Gatliff wrote:
> Some devices, like accelerometers, can manufacture as many input
> events as userspace can consume.  The traditional method for limiting
> the number of input events sent to userspace by such devices is to use
> a kernel thread looping around an idle timer, to "throttle" the
> creation and queuing of input events to a manageable rate.  Such
> drivers often also provide a sysfs attribute (or similar means) that
> allows userspace to indicate a desired event rate.
>
> Some operating systems and/or applications e.g. Android, might prefer
> to control input event creation rates themselves.  They frequently
> attempt to do so by implementing a userspace polling thread that loops
> around an idle timer; this idle timer throttles the rate of calls to
> the input devices' read() method, which (at least in theory) limits
> the rate of input events arriving at the application to a desired
> level.

In addition, we do have open/close and EV_ABS fuzz ioctl as two
existing, user-controllable throttling techniques. Additional filter
possibilities might do the trick?

> The enclosed patch address all of the above problems by implementing
> an advisory callback from the evdev read() and poll() methods to the
> associated input device driver.  The driver may then choose to
> populate the input event buffer at that time, rather than on a
> schedule implemented by a polling loop, sysfs trigger, or other means.

As already stated, this does not play very well with the event model.

> Use of this callback by a driver naturally synchronizes the generation
> of input events to requests from userspace, because the driver now
> "knows" when userspace is attempting to retrieve an input event and
> can therefore produce one just-in-time.  It also allows the driver to
> easily match the rate of input event generation, by simply sampling the
> hardware only during this callback.

The same effect could be achieved if the driver could simply ask the
input core if the read buffers are being emptied or not.

> If an input device driver chooses to use only the read() callback as
> its signal to produce an input event, then the driver need not
> implement a polling kernel thread or other means of pacing its event
> generation rate.

There is a generic polled input device for that.

> The driver also has no need to provide a sysfs
> attribute to allow userspace to request a polling rate or to trigger a
> measurement: userspace must only read() or poll() the interface at the
> desired rate.  This can greatly simplify input device driver
> implementation, while conveniently leaving the incoming event rate and
> synchronization issues completely up to the application. (See POSIX.1b
> interval timers and scheduler options for APIs allowing precise timing
> within user applications).

Right, rate adaption should be transparent and automatic.

> Finally, input device drivers might choose to implement a holdoff
> timer that gets reset in the read() callback; expiration of this timer
> would mean that userspace is no longer actively reading from the
> device, even though the interface itself might still be open.  In such
> cases the driver might wish to invoke a power-management method to
> idle the hardware until the next  callback occurs.

Or userspace could actually close the device to accomplish the desired
effect with existing infrastructure.

> Polled devices like accelerometers and compasses (and perhaps some
> types of pushbuttons or switch inputs) will get the most benefit from
> utilizing the read() callback.  Other devices, like USB keyboards and
> mice, will have no use for it and may safely ignore it.

Thanks,
Henrik