On Thu, Dec 02, 2010 at 03:34:20PM -0600, Bill Gatliff wrote: > Guys: > > > > On Thu, Dec 2, 2010 at 3:22 PM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > We do not have such fine granularity as per-read. Input drivers get > > notified when first application opens one of the interfaces (by > > implementing input->open()). We expect that applications that open > > input interfaces will read the data from them. > > Right, I know that applications will ultimately read from the interface. :) > > I have noticed that several Android ports (among others) call read on > /dev/input/eventX inside of a delayed loop--- as if they want to pace > the rate of incoming events themselves. In fact, in those ports the > length of each delay is controlled by how often Android applications > a.k.a. Activities want events streamed to them. > > This is a great idea in theory, especially for things like > accelerometers which can go much, much faster than an activity might > need the data. But I just haven't seen anywhere in those > aforementioned ports where the pacing information gets conveyed over > to the kernel-side driver. You have answered my basic question, > however: if such information gets conveyed back to a driver, it > doesn't get there through the evdev interface! > > Would a patch that adds a read callback, similar to how open works > now, be well-received? I can see it being very useful for certain > situations... > 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. I'd say applications that really want this behavior simply need to go through open/read/close cycles. -- 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
