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:38:12 -0800
From:	Dima Zavin <dmitriyz@...gle.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	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

>> 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.).

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