Re: Synchronizing evdev readers and drivers?

[Bill Gatliff <bgat@billgatliff.com>]

Dmitry:

On Fri, Dec 3, 2010 at 1:32 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> How would the driver know if application that is opened the device
> does not want to be aware of the events that happened before read as
> opposed to the application that simply choses to "batch" events and
> process them at once? The driver might not be able to retrieve the "old"
> state of the hardware. Lets say toggle WIFI button was pressed and
> released while application wasn't reading. Normally kernel would queue
> the events and when userspace read the FD they'd see events, whereas in
> your case events would be lost.

Good question.

What I'm proposing is really useful only for embedded work, where you
have absolute control (or at least understanding) over what the
hardware and driver stack looks like.  If one wanted to see all the
transitions of the WiFi button (to use your example), they'd bind the
hardware to a driver that worked that way.  The system integrator
would make the choice, not the application.

In situations where an application wanted the accumulating behavior
sometimes, and the stateless behavior at other times, then the system
integrator could provide for that by using two different event
interfaces, one for each personality.  I think...

> I'd say applications that really want this behavior simply need to
> go through open/read/close cycles.

Wow, that seems really, really expensive at a sampling rate of 100+Hz.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com