lkml.org 
[lkml]   [2010]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2010-03-03 20:11    [W:0.080 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site