Re: [GIT PULL] Ambient Light Sensors subsystem



On Tue, 2 Mar 2010, Dima Zavin wrote:

I definitely see the need for what you guys are trying to accomplish.
For example, currently, we use an input device for reporting events,
and a separate misc device node for control
(enable/disable/configure). It's definitely suboptimal, but there
currently isn't anything there would let us do things cleanly.

I have to say, I personally don't see why something like an ambient light
sensor _isn't_ just an input device.

What's the difference between a physical "increase screen brightness" key,
and a "ambient light sensor"? Absolutely none as far as I can tell.

And for something like an X server, it sounds a lot more natural to just
have another input device than to have yet abother event reporting
interface.

And quite frankly, the "explanations" I see in this thread for why it
needs to be a subsystem of its own don't actually explain anything or make
sense. They seem to boil down to "we just did it this way" without
actually answering any of the issues brought up.

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

Relevant Pages

  • Re: [GIT PULL] Ambient Light Sensors subsystem
    ... For example, currently, we use an input device for reporting events, ... I personally don't see why something like an ambient light ... What's the difference between a physical "increase screen brightness" key, ... Because in general ambient light sensor may have nothing to do with the ...
    (Linux-Kernel)
  • Re: [GIT PULL] Ambient Light Sensors subsystem
    ... For example, currently, we use an input device for reporting events, ... I personally don't see why something like an ambient light ... and a "ambient light sensor"? ... have another input device than to have yet abother event reporting ...
    (Linux-Kernel)