Re: [GIT PULL] Ambient Light Sensors subsystem

[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
--
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/