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... 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
