Hi,

On Mon, 30 Aug 2010 15:43:52 -0700, Dmitry Torokhov
[off-list ref] wrote:

On Mon, Aug 30, 2010 at 03:05:32PM -0700, Linus Torvalds wrote:

quoted

On Monday, August 30, 2010, Dmitry Torokhov [off-list ref]
wrote:

quoted

That is why I started taking accelerometers in. But I am concerned

that

quoted

quoted

taking accelerometers (which indeed are most often input devices)

will

quoted

quoted

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?

quoted

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.

I disagree. If the device is used as input and currently
app developers have to find other ways to use such input
data, having a standard interface other than input layer
will just make the mess standardized, but it will still
be a mess.

quoted

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?

Why are we trying to overengineer on such simple devices ? Wasn't
it so that we will design and implement solutions when the problem
arrives ? Why are we trying to think of all cases such a simple
device might be used just for the sake of not being input device ?

quoted

quoted

quoted

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

it might not be used on a game, but on a map application, that IS input.
You're failing to see input devices are used in cases other than gaming.

-- 
balbi