1 |
3 |
xianfeng |
LED handling under Linux
|
2 |
|
|
========================
|
3 |
|
|
|
4 |
|
|
If you're reading this and thinking about keyboard leds, these are
|
5 |
|
|
handled by the input subsystem and the led class is *not* needed.
|
6 |
|
|
|
7 |
|
|
In its simplest form, the LED class just allows control of LEDs from
|
8 |
|
|
userspace. LEDs appear in /sys/class/leds/. The brightness file will
|
9 |
|
|
set the brightness of the LED (taking a value 0-255). Most LEDs don't
|
10 |
|
|
have hardware brightness support so will just be turned on for non-zero
|
11 |
|
|
brightness settings.
|
12 |
|
|
|
13 |
|
|
The class also introduces the optional concept of an LED trigger. A trigger
|
14 |
|
|
is a kernel based source of led events. Triggers can either be simple or
|
15 |
|
|
complex. A simple trigger isn't configurable and is designed to slot into
|
16 |
|
|
existing subsystems with minimal additional code. Examples are the ide-disk,
|
17 |
|
|
nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
|
18 |
|
|
optimises away.
|
19 |
|
|
|
20 |
|
|
Complex triggers whilst available to all LEDs have LED specific
|
21 |
|
|
parameters and work on a per LED basis. The timer trigger is an example.
|
22 |
|
|
|
23 |
|
|
You can change triggers in a similar manner to the way an IO scheduler
|
24 |
|
|
is chosen (via /sys/class/leds//trigger). Trigger specific
|
25 |
|
|
parameters can appear in /sys/class/leds/ once a given trigger is
|
26 |
|
|
selected.
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
Design Philosophy
|
30 |
|
|
=================
|
31 |
|
|
|
32 |
|
|
The underlying design philosophy is simplicity. LEDs are simple devices
|
33 |
|
|
and the aim is to keep a small amount of code giving as much functionality
|
34 |
|
|
as possible. Please keep this in mind when suggesting enhancements.
|
35 |
|
|
|
36 |
|
|
|
37 |
|
|
LED Device Naming
|
38 |
|
|
=================
|
39 |
|
|
|
40 |
|
|
Is currently of the form:
|
41 |
|
|
|
42 |
|
|
"devicename:colour"
|
43 |
|
|
|
44 |
|
|
There have been calls for LED properties such as colour to be exported as
|
45 |
|
|
individual led class attributes. As a solution which doesn't incur as much
|
46 |
|
|
overhead, I suggest these become part of the device name. The naming scheme
|
47 |
|
|
above leaves scope for further attributes should they be needed.
|
48 |
|
|
|
49 |
|
|
|
50 |
|
|
Known Issues
|
51 |
|
|
============
|
52 |
|
|
|
53 |
|
|
The LED Trigger core cannot be a module as the simple trigger functions
|
54 |
|
|
would cause nightmare dependency issues. I see this as a minor issue
|
55 |
|
|
compared to the benefits the simple trigger functionality brings. The
|
56 |
|
|
rest of the LED subsystem can be modular.
|
57 |
|
|
|
58 |
|
|
Some leds can be programmed to flash in hardware. As this isn't a generic
|
59 |
|
|
LED device property, this should be exported as a device specific sysfs
|
60 |
|
|
attribute rather than part of the class if this functionality is required.
|
61 |
|
|
|
62 |
|
|
|
63 |
|
|
Future Development
|
64 |
|
|
==================
|
65 |
|
|
|
66 |
|
|
At the moment, a trigger can't be created specifically for a single LED.
|
67 |
|
|
There are a number of cases where a trigger might only be mappable to a
|
68 |
|
|
particular LED (ACPI?). The addition of triggers provided by the LED driver
|
69 |
|
|
should cover this option and be possible to add without breaking the
|
70 |
|
|
current interface.
|
71 |
|
|
|