On 03/07/10 20:42, Dmitry Torokhov wrote:> On Wed, Mar 03, 2010 at 01:51:07PM -0800, Linus Torvalds wrote:>>>>>> On Wed, 3 Mar 2010, Dima Zavin wrote:>>>>>> Actually, accelerometers fit into that model fine. They have some>>> variable number of absolute axes (3, 6, etc.).>>>> In fact, they obviouslya also do end up being used exactly like joysticks >> in real life, and joysticks are commonly starting to have accelerometers >> in them (ie any modern game console controller).>>>> So treating an accelerometer like a joystick - regardless of whether it >> happens to be internal to the device or happens to be external in a >> separate controller - is not all that far-fetched anyway.>>> > But the point is that not every accelerometer is a joystick. We have> hdaps and friends that have accelerometers inside but that is not their> main purpose (they do export a secondary joystick-like interface and> that is fine), and I am pretty sure that there are other users of> accelerometers in various systems.> > I am retty sure that once we settle on the proper interface for such> sensors we should be able to write a bridge to input layer so they can> be easily used as [human] input devices in cases whether it is desired.> I agree, this should certainly be possible.

In IIO's case (as that is what I am familiar with), polled input deviceswould effectively supply a software trigger that would in turn lead tothe device pushing data into an IIO buffer. In this case the buffer wouldjust be a direct hook into input. At the moment, the only complex caseI can think of is passing events (in IIO terminology, these are thingslike crossing of thresholds) as they are not pushed out via an interfacethat currently has any hooks for in kernel use. It should be easy enoughto add such hooks though. Devices where the data flow is interrupt driveneffectively supply their own trigger anyway and are even simpler to handle.

The one remaining thing I'm trying to work out is whether to support switchingthe buffer type at runtime (rather fiddly) or just make it a compile time option(probably what will happen first in any case).

We'll also need some userspace magic to set up the linkage but that should befairly straight forward. 1) Request an input-iio-bridge (this will probablyinvolve also identifying what sort of data is coming in so as to add therelevant 'header' type information to the input events, 2) Link up the pollroute (done by name) 3) link up the buffer route (also done by name) 4) Attachthe currently non existent 'event' hooks between the two event systems (againthis will need to deal with translation and attaching the 'header' informationthat input expects.)

So not too bad. I'll hack together a proof of concept together at some point.

Jonathan

I've cc'd linux-iio to see if anyone else has thoughts on how we would do it.