Blame view
Documentation/leds-class.txt
3.81 KB
75c1d31d9 [PATCH] LED: clas... |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
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. |
0013b23d6 leds: disable tri... |
22 23 24 25 26 27 |
The timer trigger will periodically change the LED brightness between LED_OFF and the current brightness setting. The "on" and "off" time can be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds. You can change the brightness value of a LED independently of the timer trigger. However, if you set the brightness value to LED_OFF it will also disable the timer trigger. |
75c1d31d9 [PATCH] LED: clas... |
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
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: |
6c152beef leds: Standardise... |
47 |
"devicename:colour:function" |
75c1d31d9 [PATCH] LED: clas... |
48 49 50 51 |
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 |
6c152beef leds: Standardise... |
52 53 |
above leaves scope for further attributes should they be needed. If sections of the name don't apply, just leave that section blank. |
75c1d31d9 [PATCH] LED: clas... |
54 |
|
4c79141d2 leds: Add support... |
55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
Hardware accelerated blink of LEDs ================================== Some LEDs can be programmed to blink without any CPU interaction. To support this feature, a LED driver can optionally implement the blink_set() function (see <linux/leds.h>). If implemeted, triggers can attempt to use it before falling back to software timers. The blink_set() function should return 0 if the blink setting is supported, or -EINVAL otherwise, which means that LED blinking will be handled by software. The blink_set() function should choose a user friendly blinking value if it is called with *delay_on==0 && *delay_off==0 parameters. In this case the driver should give back the chosen value through delay_on and delay_off parameters to the leds subsystem. |
0013b23d6 leds: disable tri... |
69 70 71 |
Setting the brightness to zero with brightness_set() callback function should completely turn off the LED and cancel the previously programmed hardware blinking function, if any. |
4c79141d2 leds: Add support... |
72 |
|
75c1d31d9 [PATCH] LED: clas... |
73 74 75 76 77 78 79 |
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. |
75c1d31d9 [PATCH] LED: clas... |
80 81 82 83 84 85 86 87 88 |
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. |