Re: [PATCH] input: evdev: Add a read() callback

2011-02-26 Thread Mark Brown
On Fri, Feb 25, 2011 at 08:46:24PM -0600, Bill Gatliff wrote: On Mon, Feb 21, 2011 at 10:33 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: But surely the most obvious solution here is to standardise a rate control interface? Yes, and no. A standardized rate control interface

Re: [PATCH] input: evdev: Add a read() callback

2011-02-21 Thread Mark Brown
On Mon, Feb 21, 2011 at 08:18:50AM -0600, Bill Gatliff wrote: But implementing a rate-specifying sysfs attribute isn't enough, however. Under the Linux kernel's current input device buffering scheme, drivers and applications can create and consume input events every 100ms, for example, but

Re: [PATCH] input: evdev: Add a read() callback

2011-02-21 Thread Bill Gatliff
Mark: Thanks for the great feedback! In a nutshell, I agree with your summary stating that my proposal is going to cause problems for applications that try to do the right thing. Were my suggestion to be adopted immediately and across the board, things would turn hairy indeed! I'm actually

Re: [PATCH] input: evdev: Add a read() callback

2011-02-21 Thread Mark Brown
On Mon, Feb 21, 2011 at 10:07:12PM -0600, Bill Gatliff wrote: A good case in point comes up when someone moves an Android implementation from one platform to another. No two accelerometer drivers seem to agree on how to specify the desired event generation rate, so the migration effort is