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]

Date:	Wed, 3 Mar 2010 23:29:43 +0400
From:	Manu Abraham <abraham.manu@...il.com>
To:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Dima Zavin <dmitriyz@...gle.com>,
	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Amit Kucheria <amit.kucheria@...durent.com>,
	Jean Delvare <khali@...ux-fr.org>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

On Wed, Mar 3, 2010 at 11:20 PM, Jonathan Cameron
<kernel@...23.retrosnub.co.uk> wrote:
> On 03/03/10 18:52, 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_.
> Just one small clarification here.  It behaves a lot more like the axis of
> a joystick.  These sensors report illuminance, not merely a binary result.
> Some of them do have sophisticated threshold type logic, but
> all of them we have seen so far allow direct reading of the value.  Typical
> uses include things like long term environmental monitoring as
> well as screen brightness.  I have at least one Mote on my desk that has a
> ambient light sensor and no ability whatsoever to drive a screen.
> (Not that this effects whether input would make sense anyway!)


Maybe it make sense to put all Generic sensors into one whole lot,
where an application can

- read the value from the driver (eg: 0 - 65535)

- read from device static information (to identify how the application
should treat the values read back.)

   - report what type of device it is (Light, Voltage, Acceleration
and what not, simple enumeration will help, mayeb you can even have
bitwise OR the types, so that you can have a driver with multiple
capabilities)
   - the max value it can go
   - the min value it can go
   - the number of steps (gradient) that the driver can do.


Maybe such a simplistic interface does help ?

The application can simply read the static information from the driver
and decide whether it should really handle that driver class.


Regards,
Manu
--
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/