Ambient Light Sensors subsystem
in [Kernel]
|
Prev: linux-next: build failure after merge of the driver-core tree
Next: linux 2.6.32 and 2.6.26 nat with pppoe throughput is very different.
From: Dmitry Torokhov on 3 Mar 2010 13:50 On Wed, Mar 03, 2010 at 09:03:16AM -0800, Linus Torvalds wrote: > > > On Tue, 2 Mar 2010, Dima Zavin wrote: > > > > I definitely see the need for what you guys are trying to accomplish. > > For example, currently, we use an input device for reporting events, > > and a separate misc device node for control > > (enable/disable/configure). It's definitely suboptimal, but there > > currently isn't anything there would let us do things cleanly. > > I have to say, I personally don't see why something like an ambient light > sensor _isn't_ just an input device. > > 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... > > And for something like an X server, it sounds a lot more natural to just > have another input device than to have yet abother event reporting > interface. > 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. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 3 Mar 2010 14:00 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. > 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. 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. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 3 Mar 2010 14:10 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 3 Mar 2010 14:20 On 03/03/10 18:52, 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_. Just one small clarification here. It behaves a lot more like the axis of a joystick. These sensors report illuminance, not merely a binary result. Some of them do have sophisticated threshold type logic, but all of them we have seen so far allow direct reading of the value. Typical uses include things like long term environmental monitoring as well as screen brightness. I have at least one Mote on my desk that has a ambient light sensor and no ability whatsoever to drive a screen. (Not that this effects whether input would make sense anyway!) > > 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. > >> 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. > > 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. In principle I agree, but the current situation was also causing problems. Within the mainline and other incoming trees there were 4 drivers for light sensors. Each one was in a different 'subsystem' (one was in misc) and each was exporting data to userspace via different interface causing all sorts of fun for userspace developers. The core of the subsystem is really just a small amount of documentation and a class to give a common location (which we could drop; it is merely a convenience for userspace). Perhaps we just provide the documentation and move the lot into misc? Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 3 Mar 2010 14:40
Hi Dmitry, >>>> 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. We are working on it, but unfortunately the 'fast' end of the scale is making it rather complex beast and there is still a fair bit of work to be done before we suggest merging into the main tree. We allow for 'simple' drivers that do have very similar functionality to ALS as proposed. (i.e. they just handle some sysfs interfaces and device registration). I certainly have no objection to taking light sensors back into IIO. (one never moved out!) Obviously I'll want opinions from the individual driver developers before doing this. As things currently stand it involves moving drivers out of mainline into staging. Whilst we have numerous drivers being developed against the subsystem as is, elements of it (including the userspace api) are still changing. ALS actually grew out of ACPI and as Zhang Rui was proposing a subsystem that got a positive response on LKML, quick discussions amongst IIO devs came to the conclusion that these particular drivers actually overlap hardly at all in terms of functionality with the rest of our devices set so there would be no loss in moving them out and considerable gain in giving them a stable user interface etc. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |