Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input:CMA3000 Accelerometer driver)
From: Jonathan Cameron
Date: Tue Aug 31 2010 - 14:10:33 EST
On 08/31/10 18:24, Mohamed Ikbel Boulabiar wrote:
> IMHO I think sensors no more can be considered as non-input-devices.
> Things changed too much in recent years. Input "sources" have now a
> very different use as before (smartphones, Tablets and handheld
> devices...)
> They all have much inputs that come mostly from sensors.
>
> So the definition of an input device is something that the user can
> interact on it ?
Sadly it is no where near as clean a definition as we would like.
There are too many fuzzy regions. Lots of the devices are used for
both consumer devices and for other forms of high end input. A lot
of consumer devices use general purpose ADCs at a tiny percentage of
their maximum data rates because they are cheap and standard.
> Maybe we should consider input devices to be made from 1 to N sensors
> with some filtering blocks which only expose the useful data.
That's what you get via input (to a certain extent). But a lot of what
people want in applications is derived data and some of the algorithms
to do that are very complex and certainly should not be in the kernel.
Again this may be a case for using uinput to push your derived data back
into kernel space. (Did I mention that I rather like uinput now I've
started playing with it :)
>
> If we think like this an input device can be made from sub parts which
> can be bare sensors. (Many sensors are exposed as
> Human.Interface.Devices which are mainly input devices)
HID is just fine if the aggregation is nicely handled by a separate
processor on the device (which is what is actually happening). It
is large, messy and an enormous number of devices abuse it for things
that aren't input. They have exactly the same issue that Dmitry
is trying to avoid. Just because you can use an interface to handle
your data, doesn't make it the right thing to do!
Hence HID is a very nice illustration in lots of ways ;)
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/