Messages in this thread | | | Date | Wed, 3 Mar 2010 11:07:54 -0800 | From | Dmitry Torokhov <> | Subject | Re: [GIT PULL] Ambient Light Sensors subsystem |
| |
On Wed, Mar 03, 2010 at 10:52:43AM -0800, Linus Torvalds wrote: > > > On Wed, 3 Mar 2010, Dmitry Torokhov wrote: > > > On Wed, Mar 03, 2010 at 09:03:16AM -0800, Linus Torvalds wrote: > > > > > > What's the difference between a physical "increase screen brightness" key, > > > and a "ambient light sensor"? Absolutely none as far as I can tell. > > > > Because in general ambient light sensor may have nothing to do with the > > screen brightness. The fact that all current uses are tied to > > controlling screen brightness is coincidential. You could use it as well > > to turn on the lights in the kitchen if it is getting too dark... > > But my point is, it acts pretty much like a key on a keyboard > _regardless_. > > Sure, you migth use it to turn up the lights too. But how is that > different from having a switch to do the same? Again, it doesn't sound > that different from a key to me.
I guess for me the distinction is that the event was not caused by an action of a human being but by change in environment.
Also, if we decide that input layer is the best place for such devices, it should not be a key but absolute event, ABS_LIGHT_LEVEL or something.
> > > Yes, it is easier, but it is not necessarily the right interface. I > > still believe in using input layer for human iteraction events, and not > > as generic transport a-la netlink or uevent. Voltage measurements, > > network cable presence notifications, ambient light/temperature sensors, > > and so forth do not belong here. > > The thing is, if the choice is about a whole new subsystem just for some > silly light sensor logic, I'd _much_ rather see the much simpler - and > more useful - approach of just considering it an input event. > > It happens in the same kind of situations, it has the same kinds of timing > issues (ie we're not talking streaming megabytes of data), and it has the > same kind of users (ie a lightsensor really would be used along with > something that cares about input). > > I agree that that's not true in many other situations. A cable insertion > event is about the networking, not about some independent input. The kind > of application that cares about network cable presense is _not_ the kind > of app that would care about keyboard input. Same goes for voltage.
What about magnetometers, accelerometers and so forth? I still do not think they are pure input layer devices although it is possible to build a bridge modules so they could plug into input framework if desired.
> > That said, I'm not married to the whole "it has to be input layer". But I > _do_ think that it's crazy to start doing new subsystems for every little > thing. That way lies madness. >
I was hoping IIO would fill the niche of framework for generic data acquisition devices, regardless of how fast or slow they are.
-- Dmitry
| |