linux-kernel - Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C7D46A1.7070101@jic23.retrosnub.co.uk>
Date:	Tue, 31 Aug 2010 19:14:57 +0100
From:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
To:	Mohamed Ikbel Boulabiar <boulabiar@...il.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Felipe Balbi <me@...ipebalbi.com>, Hemanth V <hemanthv@...com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"igor.stoppa@...ia.com" <igor.stoppa@...ia.com>,
	"kai.svahn@...ia.com" <kai.svahn@...ia.com>,
	"matthias.nyman@...ia.com" <matthias.nyman@...ia.com>,
	Stéphane Chatty <chatty@...c.fr>
Subject: Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input:
 CMA3000 Accelerometer driver)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/