Message-ID: <20100831170923.GB30947@core.coreip.homeip.net>
Date:	Tue, 31 Aug 2010 10:09:23 -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 05:59:37PM +0100, Alan Cox wrote:
> > > 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.

"Data acquisition devices" then?

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

I knew it! Its all Vojtech's fault.

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

OK, so let's say we start moving some of the devices into input. Which
ones we consider suitable for input? I guess some 3-digit
accelerometers, what else? Also, what new event types would we need?
Let's take GPS - I do not think that ABS_X and ABS_Y are the best events
to be used for such devices: I am trying to allow applications being
ignorant of what exact device they are talking to and rather concentrate
on device capabilities (list of events supported). GPS is sufficiently
different from a tablet/touchscreen; while some might want to use both
as inputs to a game most applications would want to know which one
which. 

Also, GPS, liek ALS, would probably be polling, no?

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

Powered by blists - more mailing lists