[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Mar 2010 17:51:14 +0000
From: Jonathan Cameron <jic23@....ac.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Dima Zavin <dmitriyz@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Zhang Rui <rui.zhang@...el.com>,
Amit Kucheria <amit.kucheria@...durent.com>,
Jean Delvare <khali@...ux-fr.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem
Cc'ing Input list and maintainer.
>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists