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

[Jonathan Cameron <jic23@cam.ac.uk>]

On 09/24/10 14:02, Pavel Machek wrote:
> Hi!
> 
>>> 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.
> 
> That's very similar to analog joysticks, no?
Yes, but typically much slower. Maybe a couple of times a second at most.
Some of them do support events.  The original proposal didn't include these
as no driver at the time supported them. drivers/staging/iio/light/tsl2563.c
does now though. Given the low rates, we did discuss doing this via select
on sysfs attributes (driven off underlying hardware interrupts).
> 
>>> 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
> 
> I'd not put GPS into input; yes, they do present 'x,y,z' in meters,
> but that's not what users want. 'lat,lon,alt' is better, but it is
> actually 'lat,lon,herror,alt,verror,time' and a lot of other
> metadata...
> 
> Also, we already have driver for GPSes, its called gpsd. I'd leave
> GPSes out of input.
> 
>> Also, GPS, liek ALS, would probably be polling, no?
> 
> Normally, GPS just sends you position info once a second.