Mark: On Mon, Feb 21, 2011 at 10:33 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > But surely the most obvious solution here is to standardise a rate > control interface? Yes, and no. A standardized rate control interface would deal with the rate control problem, but leave the synchronization problem unsolved. > The problem you're trying to solve is also an issue for really common > and standard things like touchscreens and polled switches/keys (the > latter of which you mentioned in your mail) which are used by standard > applications. The existing "polled switch" implementation sets up a throttled polling loop in kernel code. The "polled switch" that I was thinking of when I wrote the essay for the commit was "a switch that is polled each time read() gets called". I should have been clearer--- and probably picked a different name. :) > Have you looked at the IIO subsystem for things like this? There has > been talk of putting accelerometers in there and it certainly fits in > with the sync requirements you're mentioning. Now that I have found the code, I'm looking at it. Can't say yet whether it's the solution I'm seeking, or not. > The problem with your proposal as it stands is that if they do use the > new interface they interact badly with existing applications. This > isn't really a decision the driver should be taking, it needs to be > userspace policy if it's going to be a decision at all. Yea, I'm agreeing with you more than I was at the beginning of this thread. 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
