ia64/linux-2.6.18-xen.hg

annotate Documentation/leds-class.txt @ 524:7f8b544237bf

netfront: Allow netfront in domain 0.

This is useful if your physical network device is in a utility domain.

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