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 13:56:45 -0800
From:	Mike Chan <mike@...roid.com>
To:	Dima Zavin <dmitriyz@...gle.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

On Wed, Mar 3, 2010 at 1:38 PM, Dima Zavin <dmitriyz@...gle.com> wrote:
>>> 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.
>>
>> Also, if we decide that input layer is the best place for such devices,
>> it should not be a key but absolute event, ABS_LIGHT_LEVEL or something.
>
> Agreed, a key is not the best approach. We currently have been hacking
> around it by using ABS_MISC, which I know is wrong.
>
>>> The thing is, if the choice is about a whole new subsystem just for some
>>> silly light sensor logic, I'd _much_ rather see the much simpler - and
>>> more useful - approach of just considering it an input event.
>>>
>>> It happens in the same kind of situations, it has the same kinds of timing
>>> issues (ie we're not talking streaming megabytes of data), and it has the
>>> same kind of users (ie a lightsensor really would be used along with
>>> something that cares about input).
>>>
>>> I agree that that's not true in many other situations. A cable insertion
>>> event is about the networking, not about some independent input. The kind
>>> of application that cares about network cable presense is _not_ the kind
>>> of app that would care about keyboard input. Same goes for voltage.
>>
>> What about magnetometers, accelerometers and so forth? I still do not
>> think they are pure input layer devices although it is possible to build
>> a bridge modules so they could plug into input framework if desired.
>
> Actually, accelerometers fit into that model fine. They have some
> variable number of absolute axes (3, 6, etc.).
>

Slightly off topic here, but with the introduction of an als
subsystem, wouldn't you want to unify how the kernel export lux
values? Currently it seems the driver can export whatever they want to
export, lux or lumen, whatever they want.

-- Mike

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