On Thu, Dec 02, 2010 at 03:34:20PM -0600, Bill Gatliff wrote: > 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. The sysfs interface offered by polldev is *mostly* doing the same thing (providing user space control of the sample rate) - see "Input: input-polldev - add sysfs interface for controlling poll interval". Implementing the same interface for other input devices seems like a reasonable approach to the problem? It would mean that if the hardware is capable of autonomously controlling the rate at which it generates samples the application would be able to take advantage of that. A callback on read seems like it's a bit limited as it's more work for the application (handling the latency introduced by waking up from your delay and doing the read is faff) and requires polling in the hardware too. -- 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
