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 11:07:54 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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 Wed, Mar 03, 2010 at 10:52:43AM -0800, 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_. 
> 
> 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.

> 
> > Yes, it is easier, but it is not necessarily the right interface. I
> > still believe in using input layer for human iteraction events, and not
> > as generic transport a-la netlink or uevent. Voltage measurements,
> > network cable presence notifications, ambient light/temperature sensors,
> > and so forth do not belong here.
> 
> 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.

> 
> That said, I'm not married to the whole "it has to be input layer". But I 
> _do_ think that it's crazy to start doing new subsystems for every little 
> thing. That way lies madness. 
>

I was hoping IIO would fill the niche of framework for generic data
acquisition devices, regardless of how fast or slow they are.

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