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] [day] [month] [year] [list]

Message-ID: <20100322042742.GB31621@core.coreip.homeip.net>
Date:	Sun, 21 Mar 2010 21:27:42 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

On Mon, Mar 22, 2010 at 01:13:29AM +0100, Jan Engelhardt wrote:
> 
> On Wednesday 2010-03-03 20:07, Dmitry Torokhov wrote:
> >On Wed, Mar 03, 2010 at 10:52:43AM -0800, Linus Torvalds wrote:
> >> On Wed, 3 Mar 2010, Dmitry Torokhov wrote:
> >>> 
> >>> 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.
> 
> Power failure is also usually not caused by an action of a human, and
> yet, (some brands/models of) uninterruptible power supplies present
> these events through USBHID/input.

USBHID - yes, input - no. Let's not confuse transport with subsystem.

As we witnessed in another thread some vendors used HID for industrial
sensors (temperature IIRC) and write applications using joystick
interface (/dev/input/jsX). It does not mean this is the best approach.

Same goes for laptop vendors using 'free' scancodes to deliver
additional events via i8042. The fact that they "extend" KBC data
stream still does not make them input events.

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