linux-kernel - Re: [GIT PULL] Ambient Light Sensors subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <404ea8001003072229n47269b44r5d1fc17385c5bbc9@mail.gmail.com>
Date:	Sun, 7 Mar 2010 22:29:35 -0800
From:	Dima Zavin <dmitriyz@...gle.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	Jonathan Cameron <kernel@...23.retrosnub.co.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Amit Kucheria <amit.kucheria@...durent.com>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

On Sun, Mar 7, 2010 at 12:49 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Wed, Mar 03, 2010 at 03:08:29PM -0800, Dima Zavin wrote:
>>
>> As it came up earlier in the thread, adding an ABS_AMBIENT_LIGHT_LEVEL
>> or equivalent is much simpler and provides a clean, concise, and
>> useful interface to userspace.
>>
>> Note that for many applications, you actually get configurable
>> threshold levels, and the hardware triggers an interrupt when the
>> light level crosses those thresholds. This makes using an input device
>> very useful, and that is in fact how we use ALS devices today. I have
>> several pieces of hardware that do this, and I don't see how this new
>> als subsystem helps me handle that problem. With the suggested API,
>> I'll have to poll the sysfs files manually to see if they've changed
>> (which is suboptimal), or still add a non-standard input device to do
>> what I want.
>>
>
> OK, so from what you are saying it looks you just like the _interface_,
> or transport, that input subsystem provides, not the fact that you
> considering the device to be a HID-type device. If this is the case then
> this indicates that we need to take another look at the proposed
> interface and make sure that it allows proper poll() support.

Yes, you are right. Though, the filtering that the input subsystem
provides can also be useful.

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