Dmitry: On Fri, Dec 3, 2010 at 1:32 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
