Hi, On Mon, 30 Aug 2010 15:43:52 -0700, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > 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. 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. >> 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 ? >> >> (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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
