On Fri, Dec 03, 2010 at 11:36:50AM -0600, Bill Gatliff wrote: > Mark: > > > On Fri, Dec 3, 2010 at 7:53 AM, Mark Brown > <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Surely that's what poll() and whatnot are for? If userspace has to poll > > at all that seems to be a failure in itself. > > The poll() and blocking read() system calls allow an application to > tell an input device that it is prepared to receive an event, and for > an input device driver to tell userspace when an event has occurred. > As implemented in evdev, however, neither system call provides a > natural, consistent way for userspace to tell an input device driver > how often it wants data--- or even if it wants any (at the moment) at > all. Right. The indication that application wants the data is open() call. If userspace does not want data, it should close() the interface. Drivers have no idea what users want to do with the data so they can't decide whether to ignore the hardware or query it and queue events up. Some applications might be interested in "sample on demand", while others would prefer events to be queued and consumed at once. [... cut long argument for an inconsistent and incompatible change to the interface ...] BTW, if application reads (supplies space for) just one event should we disacard the rest of hardware state that we read from the device? You know, just asking... -- 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
