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

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