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: <20100831175937.70a59a91@lxorguk.ukuu.org.uk>
Date:	Tue, 31 Aug 2010 17:59:37 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
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)

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

Probably because most of these devices have nothing to do with industrial
I/O at all.

> 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

That's not what I asked. 

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

That tends to make little sense where the API is the same and
applications benefit enormously from consistency. I'd rather have an
input->IIO bridge because that is the real world today !

The question is what does the API make *sense* for. Not what can you use
the API for. Unix (and Linux) are enormously powerful because of the use
of common interfaces and APIs.

So a voltmeter really makes no sense. It's not a set of keys and it
doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things
do fit this to varying degrees.

I'm actually more dubious than Linus about ALS - because ALS tends not
produce 'events' but to be sampled, and there are significant power
implications to unnecessary polling.

See it as a curse of success - because you got the API right and made it
flexible people want to use it. And the more it's used the less special
code is needed in user or kernel space for PDAs and phones - instead they
just work.

> > In a game
> > context can I suggest the Zombies game is an example ?
> 
> I am not familiar with this game, sorry.

It uses GPS and networking to stage an 'in real world' zombie dodging
game.

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