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

[Dmitry Torokhov]

On Mon, Aug 30, 2010 at 03:05:32PM -0700, Linus Torvalds wrote:
> On Monday, August 30, 2010, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> >
> > That is why I started taking accelerometers in. But I am concerned that
> > taking accelerometers (which indeed are most often input devices) will
> > lead people to try and use the same for temperature, ALS and other
> > sensors that are more often used in industrial process controls.
> 
> You're just being silly.
> 
> Nobody writes a driver for a "temperature sensor" or "ambient light
> sensor". They write a driver for a specific *chip* that is used in
> cellphones etc, and that happens to have an ambient light and
> temperature sensor on it.

And? Yes, they have a ALS and temperature sensors. They also have
voltage regulators, pwm, ADC and a bunch of other stuff wired on. You
are not arguing that all of those should be input devices just because
they happen to reside on the same chip?

> 
> And in that context, it really does make sense to see it as an input
> driver. And the fact that there are industrial uses for ALS sensors
> that aren't necessarily at all interested on the input layer should
> not matter at all.

I think it does matter; we should have standard interface for certain
functionality that makes sense for everyone. So far cellphone guys
wanted to plumb such devices through input not necessarily because these
are HID events but because:

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.

> 
> So don't bring up "ALS isn't always input" because within the context
> of a driver for some highly integrated cellphone model, it really IS
> input, and there is no ambiguity at all.
> 
> So your "sometimes it is, and sometimes it isn't" argument is bogus.
> The ambiguity simply doesn't exist when seen in context.

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?

> 
> >> (or GPS device, for that matter) really be?
> >
> > But why GPS should be input device? It has nothing to do with user
> > input.
> 
> What? OF COURSE it is an input driver. It's the user moving the device
> around. It's EXACTLY the same thing as an accelerometer in that
> respect. Sure, it's a bit less precise and measures movement wrt some
> external frame, but technically they are almost exactly the same.
> 
> If you se doing a navigation app, the accelerometer, the compass and
> the GPS are all equally (but differently) important.
> 
> Again - it's not a user touching buttons. But it IS a user moving around.

Right, but do you expect that movement to cause an immediate action?
When you press a key - something happens; when you swing a Wii
controller - the device reacts. And really you can swap joysticks,
motion controllers, Sony's 6-axis and so forth and the application would
be hard pressed to tell the difference. I am unsure how you would play a
game with GPS as an input device.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/