Ambient light sensors

By Jonathan Corbet
June 2, 2010

Ambient light sensors do exactly that: tell the system how much light currently exists in the environment. They are useful for tasks like automatically adjusting screen brightness for optimal readability. There are a few drivers for such sensors in the kernel now, but there is no standard for how those drivers should interface to user space. Andrew Morton recently noticed this problem and suggested that it should be fixed: "This is very important! We appear to be making a big mess which we can never fix up."

As it happens, the developers of drivers for these sensors tried to solve this problem earlier this year. That work culminated in a pull request asking Linus to accept the ambient light sensors framework into the 2.6.34 kernel. That pull never happened, though; Linus thought that these sensors should just be treated as another (human) input device, and others requested that it be expanded to support other types of sensors. This framework has languished ever since.

Perhaps the light sensor framework wasn't ready, but the end result is that its developers have gotten discouraged and every driver going into the system is implementing a different, incompatible API. Other drivers are waiting for things to stabilize; Alan Cox commented: "We have some intel drivers to submit as well when sanity prevails." It's a problem clearly requiring a solution, but it's not quite clear who will make another try at it or when that could happen.

Index entries for this article
Kernel	Device drivers/Industrial I/O
Kernel	Industrial I/O devices

Ambient light sensors

Posted Jun 3, 2010 3:44 UTC (Thu) by neilbrown (subscriber, #359) [Link]

I guess we need an 'API' maintainer. Someone with taste, experience, impartiality and (very importantly) time - to keep bad interfaces out, good interfaces in, and advise on converting one to the other.
And: no, a committee wouldn't work.

Future directions

Posted Jun 3, 2010 10:17 UTC (Thu) by jic23 (subscriber, #56049) [Link]

Thanks for picking up on this discussion.

ALS existed because we (those who actually wrote the drivers for these things) felt that they were so simple they didn't justify a heavyweight system, in a similar fashion to hwmon. It was really just documentation and a class (to give a common location in sysfs).

After Linus' response to my pull request, I decided to stop spending time on trying to deal with the simple cases and put it instead in to IIO (currently in staging). That is very much intended to be the general subsystem that others wanted from ALS. There are plans to add an input bridge from IIO buffers. Admittedly it isn't overwhelmingly high on our priority list as most IIO devs are primarily interested in high speed devices where doing this would be silly (anyone for a 1MHz+ 16 channel mouse?) Such a bridge has theoretical support from the input maintainer and should to a certain degree answer Linus' issues with ALS.

We are quite happy to take ambient light sensors (and indeed, tsl2563 is already in there.) Pulling the others into IIO was discussed and IIRC the developers of all of those in the kernel at the time were happy for us to do that (tsl2550 and isl2009). That we haven't is simply a case of priorities and the interesting question of whether pulling drivers out of mainline into staging is a good idea even if it does clean up these sort of interface questions.

Note we have a nice strictly defined abi to be found in drivers/staging/iio/Documentation/sysfs-class-iio. Recent abi changes to bring the tsl2563 in line with the rest of the subsystem can be found on the linux-iio archive at marc.info.

Ambient light sensors

Posted Jun 3, 2010 19:36 UTC (Thu) by davi (guest, #18853) [Link] (1 responses)

IMO it should not be set just to allow adjusting screen brightness but supply adapter to adjust: first the window's room, else the room artificial light, else the monitor screen brightness as last option.

Ambient light sensors

Posted Jun 9, 2010 9:19 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

The article seems to suggest that the sensor driver gives your userspace tool the light level, and your userspace tool uses whatever facilities are available to address the issue. At least, I hope that's the intent; anything else would seem strange.