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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
