On Fri, Dec 03, 2010 at 01:50:08PM -0600, Bill Gatliff wrote: > 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. Signficant number of drivers work in different environments as do the applications. System integrator can not make this choice since _his_ choice might be different from another system integrator's choice. > > 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... Having a diffrent interface for certain class of devices is an option. Accelerometers, magnetometers and other not pure HID devices might make use of IIO and/or sysfs. In fact, most of accelerometer drivers attempt to provide their own sysfs interfaces and among them ways to fetch current device state. This kind of interface seems to suit your needs best. Note that standardizing sysfs accelerometer inteface is under discussion and if you are interested you shoudl join it. > > > 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. First of all - not really (this how much open is similar to your callback anyway) and second - if it gets expensive you stop doing this. -- Dmitry -- 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
