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: Jonathan Cameron on 8 Mar 2010 05:30 Hi Dima, >> Anyhow, the way this conversation is going there appear to be several options >> and we need to make a decision before anyone wastes much more time. >> >> 1) ALS as is. It's extremely light weight and can always be merged with a better >> option at a later date. If people prefer we can always stick it in a subdirectory >> called sensors or similar. Perhaps move hwmon in there as well. > > If your plan is to integrate with iio when it's ready, then there will > be a drivers/iio, so creating top-level als or even drivers/sensors at > this point wouldn't really make sense. Perhaps putting them into > drivers/misc/als is more appropriate? That would work for me though it kind of breaks what I think misc is for. It's Andrew Morton's domain though... (cc'd) > >> 2) Input. I agree with Dmitry here. These devices are not within the scope as it >> currently exists. It can be done and there have been numerous discussions about >> doing so in the past (with various sensor types) and each time it has been decided >> that it isn't the right option. Perhaps opinion on this has changed? > > As Dmitry correctly distilled from my ramblings, what we really need > is support for poll() on sensor devices. If you guys add a poll > interface to als, then we can probably get by until iio gets merged. > Otherwise, we will still need to hack up an input device exporting > ABS_MISC. If we had ABS_AMBIENT_LIGHT_LEVEL, then it'd be slightly > less hacky. Adding polling (here anyway) isn't actually a part of the subsystem. Just write a driver which has some internal caching fed by relevant interrupt. Then call sysfs_notify with parameters relevant to the attribute in question. So for an illuminance0 reading say: sysfs_notify(&device->dev.kobj, NULL, "illuminance0"); This covers any cases of the device notifying of new values. You can always add 'alarm' type attributes and poll on them. The only kicker here, is that userspace that polls on a device not supporting polling will never get a response. If you need 'alarm' type parameters feel free to add them as long as they are suitable documented. > >> Please can anyone who feels like suggesting another general sensors subsystem >> at least taking a look at IIO (and keeping in mind we are in the middle of a big >> API cleanup). If you disagree with how we have done things, then contribute >> to the discussions and they may change. > > I looked into IIO (sorry for the delay), and it does look promising. > I'll try to participate in future discussions, and will provide some > more feedback in a more appropriate forum as it is likely out of scope > here. When I get a chance, I'll try moving one of our drivers to iio > and see how it goes. Excellent, I'd suggest waiting till the current round of API changes are in there. Right now you'd just end up getting it working and I'd go break the interface. Hopefully, once that's in place those elements of the userspace side of things will be more or less stable. 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: Pavel Machek on 10 Mar 2010 16:00 Hi! > > > 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. Well, I seen people covering light sensor by hand to change screen brightness :-). > 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. Yep. > > 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. At least on android, accelerometers are primarily human interaction device -- for screen rotation. And biggest use of magnetometer+accelerometer on android is actually looking around in streetview... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: Jon Smirl on 18 Mar 2010 10:40 On Sun, Mar 7, 2010 at 4:42 PM, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > On Wed, Mar 03, 2010 at 01:51:07PM -0800, Linus Torvalds wrote: >> >> >> On Wed, 3 Mar 2010, Dima Zavin wrote: >> > >> > Actually, accelerometers fit into that model fine. They have some >> > variable number of absolute axes (3, 6, etc.). >> >> In fact, they obviouslya also do end up being used exactly like joysticks >> in real life, and joysticks are commonly starting to have accelerometers >> in them (ie any modern game console controller). >> >> So treating an accelerometer like a joystick - regardless of whether it >> happens to be internal to the device or happens to be external in a >> separate controller - is not all that far-fetched anyway. >> > > But the point is that not every accelerometer is a joystick. We have > hdaps and friends that have accelerometers inside but that is not their > main purpose (they do export a secondary joystick-like interface and > that is fine), and I am pretty sure that there are other users of > accelerometers in various systems. > > I am pretty sure that once we settle on the proper interface for such > sensors we should be able to write a bridge to input layer so they can > be easily used as [human] input devices in cases whether it is desired. > Sorry for the late reply, but this is a recurring theme. Remote controls (IR and radio) have the same problem and this was the core of my objection to their drivers being merged. Input devices need to communicate their human oriented events to user space using the input subsystem period. If you don't do this things like the xserver/apps have to implement custom drivers for every new user event interface that is dreamed up and that destroys backwards compatibility. Drivers can always be split into two modules. A core module could provide a sysfs or kernel internal interface. An add-on module can optionally redirect events from the core module into the input subsystem. I'm also not a fan of having a custom interface on the sensor/input devices that reports device specific events to user space. Then those events are massaged by a tiny user space app and reinjected into the input subsystem. That does work but it leads to the kernel requiring external apps in order to function. I believe converting device specific events to a common device protocol is the work of the device driver. -- Jon Smirl jonsmirl(a)gmail.com -- 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: Jan Engelhardt on 21 Mar 2010 20:20 On Wednesday 2010-03-03 20:07, Dmitry Torokhov wrote: >On Wed, Mar 03, 2010 at 10:52:43AM -0800, Linus Torvalds wrote: >> On Wed, 3 Mar 2010, Dmitry Torokhov wrote: >>> >>> 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. Power failure is also usually not caused by an action of a human, and yet, (some brands/models of) uninterruptible power supplies present these events through USBHID/input. -- 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 22 Mar 2010 00:30
On Mon, Mar 22, 2010 at 01:13:29AM +0100, Jan Engelhardt wrote: > > On Wednesday 2010-03-03 20:07, Dmitry Torokhov wrote: > >On Wed, Mar 03, 2010 at 10:52:43AM -0800, Linus Torvalds wrote: > >> On Wed, 3 Mar 2010, Dmitry Torokhov wrote: > >>> > >>> 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. > > Power failure is also usually not caused by an action of a human, and > yet, (some brands/models of) uninterruptible power supplies present > these events through USBHID/input. USBHID - yes, input - no. Let's not confuse transport with subsystem. As we witnessed in another thread some vendors used HID for industrial sensors (temperature IIRC) and write applications using joystick interface (/dev/input/jsX). It does not mean this is the best approach. Same goes for laptop vendors using 'free' scancodes to deliver additional events via i8042. The fact that they "extend" KBC data stream still does not make them input events. -- 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/ |