Re: [GIT PULL] Ambient Light Sensors subsystem

From: Dmitry Torokhov
Date: Wed Mar 03 2010 - 14:08:16 EST

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at