diff options
Diffstat (limited to 'Documentation/leds-class.txt')
| -rw-r--r-- | Documentation/leds-class.txt | 71 |
1 files changed, 0 insertions, 71 deletions
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt deleted file mode 100644 index 8c35c042611..00000000000 --- a/Documentation/leds-class.txt +++ /dev/null @@ -1,71 +0,0 @@ -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. - |