72 lines
2.7 KiB
Plaintext
72 lines
2.7 KiB
Plaintext
|
LED handling under Linux
|
||
|
|
========================
|
||
|
|
|
||
|
|
If you're reading this and thinking about keyboard leds, these are
|
||
|
|
handled by the input subsystem and the led class is *not* needed.
|
||
|
|
|
||
|
|
In its simplest form, the LED class just allows control of LEDs from
|
||
|
|
userspace. LEDs appear in /sys/class/leds/. The brightness file will
|
||
|
|
set the brightness of the LED (taking a value 0-255). Most LEDs don't
|
||
|
|
have hardware brightness support so will just be turned on for non-zero
|
||
|
|
brightness settings.
|
||
|
|
|
||
|
|
The class also introduces the optional concept of an LED trigger. A trigger
|
||
|
|
is a kernel based source of led events. Triggers can either be simple or
|
||
|
|
complex. A simple trigger isn't configurable and is designed to slot into
|
||
|
|
existing subsystems with minimal additional code. Examples are the ide-disk,
|
||
|
|
nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
|
||
|
|
optimises away.
|
||
|
|
|
||
|
|
Complex triggers whilst available to all LEDs have LED specific
|
||
|
|
parameters and work on a per LED basis. The timer trigger is an example.
|
||
|
|
|
||
|
|
You can change triggers in a similar manner to the way an IO scheduler
|
||
|
|
is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
|
||
|
|
parameters can appear in /sys/class/leds/<device> once a given trigger is
|
||
|
|
selected.
|
||
|
|
|
||
|
|
|
||
|
|
Design Philosophy
|
||
|
|
=================
|
||
|
|
|
||
|
|
The underlying design philosophy is simplicity. LEDs are simple devices
|
||
|
|
and the aim is to keep a small amount of code giving as much functionality
|
||
|
|
as possible. Please keep this in mind when suggesting enhancements.
|
||
|
|
|
||
|
|
|
||
|
|
LED Device Naming
|
||
|
|
=================
|
||
|
|
|
||
|
|
Is currently of the form:
|
||
|
|
|
||
|
|
"devicename:colour"
|
||
|
|
|
||
|
|
There have been calls for LED properties such as colour to be exported as
|
||
|
|
individual led class attributes. As a solution which doesn't incur as much
|
||
|
|
overhead, I suggest these become part of the device name. The naming scheme
|
||
|
|
above leaves scope for further attributes should they be needed.
|
||
|
|
|
||
|
|
|
||
|
|
Known Issues
|
||
|
|
============
|
||
|
|
|
||
|
|
The LED Trigger core cannot be a module as the simple trigger functions
|
||
|
|
would cause nightmare dependency issues. I see this as a minor issue
|
||
|
|
compared to the benefits the simple trigger functionality brings. The
|
||
|
|
rest of the LED subsystem can be modular.
|
||
|
|
|
||
|
|
Some leds can be programmed to flash in hardware. As this isn't a generic
|
||
|
|
LED device property, this should be exported as a device specific sysfs
|
||
|
|
attribute rather than part of the class if this functionality is required.
|
||
|
|
|
||
|
|
|
||
|
|
Future Development
|
||
|
|
==================
|
||
|
|
|
||
|
|
At the moment, a trigger can't be created specifically for a single LED.
|
||
|
|
There are a number of cases where a trigger might only be mappable to a
|
||
|
|
particular LED (ACPI?). The addition of triggers provided by the LED driver
|
||
|
|
should cover this option and be possible to add without breaking the
|
||
|
|
current interface.
|
||
|
|
|