TODO list for LED subsystem in near future

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

Here's a bit of todos. I'm thinking about putting in into the tree as
drivers/leds/TODO. Comments? Someone willing to help?

Best regards,
								Pavel

-*- org -*-

* Review atomicity requirements in LED subsystem

Calls that may and that may not block are mixed in same structure, and
semantics is sometimes non-intuitive. (For example blink callback may
not sleep.) Review the requirements for any bugs and document them
clearly.

* LED names are still a mess

No two LEDs have same name, so the names are probably unusable for the
userland. Nudge authors into creating common LED names for common
functionality.

? Perhaps check for known LED names during boot, and warn if there are
LEDs not on the list?

* Split drivers into subdirectories

The number of drivers is getting big, and driver for on/off LED on a
i/o port is really quite different from camera flash LED, which is
really different from driver for RGB color LED that can run its own
microcode. Split the drivers somehow.

* Figure out what to do with RGB leds

Multicolor does not really know about LED color. In particular,
there's no way to make LED "white".

RGB LEDs are quite common, and it would be good to be able to turn LED
white and to turn it into any arbitrary color. It is essential that
userspace is able to set arbitrary colors, and it might be good to
have that ability from kernel, too... to allow full-color triggers.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux