1 What: /sys/class/backlight/<backlight>/bl_power
4 Contact: Richard Purdie <rpurdie@rpsys.net>
6 Control BACKLIGHT power, values are FB_BLANK_* from fb.h
8 - FB_BLANK_UNBLANK (0) : power on.
9 - FB_BLANK_POWERDOWN (4) : power off
12 What: /sys/class/backlight/<backlight>/brightness
15 Contact: Richard Purdie <rpurdie@rpsys.net>
17 Control the brightness for this <backlight>. Values
18 are between 0 and max_brightness. This file will also
19 show the brightness level stored in the driver, which
20 may not be the actual brightness (see actual_brightness).
23 What: /sys/class/backlight/<backlight>/actual_brightness
26 Contact: Richard Purdie <rpurdie@rpsys.net>
28 Show the actual brightness by querying the hardware.
31 What: /sys/class/backlight/<backlight>/max_brightness
34 Contact: Richard Purdie <rpurdie@rpsys.net>
36 Maximum brightness for <backlight>.
39 What: /sys/class/backlight/<backlight>/type
42 Contact: Matthew Garrett <mjg@redhat.com>
44 The type of interface controlled by <backlight>.
45 "firmware": The driver uses a standard firmware interface
46 "platform": The driver uses a platform-specific interface
47 "raw": The driver controls hardware registers directly
49 In the general case, when multiple backlight
50 interfaces are available for a single device, firmware
51 control should be preferred to platform control should
52 be preferred to raw control. Using a firmware
53 interface reduces the probability of confusion with
54 the hardware and the OS independently updating the
55 backlight state. Platform interfaces are mostly a
56 holdover from pre-standardisation of firmware