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]

Date:	Tue, 31 Aug 2010 13:35:49 +0100
From:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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>
Subject: Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input:
 CMA3000 Accelerometer driver)

On 08/31/10 10:44, Alan Cox wrote:
>> 1. Input transport via evdev is very convenient
>> 2. There is no other standard alternative
>>
>> Once there is standard interface for such sensors they will happily use
>> it and will not look back.
> 
> I think the fact that most of the interest in IIO is "how do we make an
> IIO/Input bridge" speaks volumes.
It isn't.  Most of the interest on LKML might be, but that is because all
of those interested in the 'industrial' side of things are keeping
their discussion on linux-iio@...r list.  Most of the noise on LKML may
be on the input bridge side, but most of the actual work and current
developers / users are not.  The needs we have are not all met by input,
(and nor should they be) hence the reason IIO exists.

Take a look at the work Analog have been doing with it. There are
few devices in their set that would fall into the blurred area we are
debating here. 3 phase energy meters for input anyone?
> 
>> Sure, for a particular cell phone there is no ambiguity, the sensor has
>> certain functionality assigned that is well known. But does this mean
>> that we should not expect parts being reused at all anymore?
> 
> If non-input uses later need non-input interfaces they can switch to that
> with an input bridge when there is one and when it happens, which
> probably won't.
I guess I'll just have to write the bridge :)  To put in userspace
code for a particular device should be trivial.  It may take a little
more time and thought to get a configurable general version in place.

It may not be the right option for some devices, but it will provide
a means if someone wants to take one of Analog's rather nice IMU's
or a 200G accelerometer and use it to drive their gaming rig ;)
Also, there are always devices using analog sensors connected to
much more general purpose ADCs to further blur the boundaries.
There has to be divide somewhere. Dmitry is merely trying to avoid
a flood of inappropriate drivers.
> 
>> I am unsure how you would play a game with GPS as an input device.
> 
> In a non-game context take a look at things like the British Museum
> application that allows you to view wherever you are and as it was long
> ago by fishing out a relevant photograph as you walk around. In a game
> context can I suggest the Zombies game is an example ?
> 
> Alan

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/