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: <20100831161730.GA30947@core.coreip.homeip.net>
Date:	Tue, 31 Aug 2010 09:17:30 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	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 Tue, Aug 31, 2010 at 10:44:46AM +0100, 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.

Like Jonathan mentioned, we so far only hear from mobile users here on
LKML.

> 
> > 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.

Would there even be an argument which subsystem to use if IIO->input
bridge existed today? Because if the answer is "no" then push into input
is driven by convenience and not because it is the right solution. 

> 
> > 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.

If application does take something as an input it does not make it
necessarily a human interface device. By this reasoning cameras should
be represented as an input devices (why, some applications take input
from it), hwmon should be input as well (detect your move from
Arkhangelsk to Cairo by changes in your chassis temperature while under
the same load?). Serial ports? Input. Sound - speech recognition should
be implemented as an input device converting microphone input directly
into EV_KEY/KEY_x stream bypassing sound subsystem completely? And if
someone decides to use it differently - why, let's just write a second
driver. This way is madness.

I really believe that input should represent purely human interface
devices, not arbitrary data acquisition devices.

> In a game
> context can I suggest the Zombies game is an example ?

I am not familiar with this game, sorry.

-- 
Dmitry
--
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/