Messages in this thread | | | Date | Wed, 3 Mar 2010 13:38:12 -0800 | Subject | Re: [GIT PULL] Ambient Light Sensors subsystem | From | Dima Zavin <> |
| |
>> 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.
Agreed, a key is not the best approach. We currently have been hacking around it by using ABS_MISC, which I know is wrong.
>> 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.
Actually, accelerometers fit into that model fine. They have some variable number of absolute axes (3, 6, etc.).
--Dima
| |