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
7 - FB_BLANK_UNBLANK (0) : power on.
8 - FB_BLANK_POWERDOWN (4) : power off
11 What: /sys/class/backlight/<backlight>/brightness
14 Contact: Richard Purdie <rpurdie@rpsys.net>
16 Control the brightness for this <backlight>. Values
17 are between 0 and max_brightness. This file will also
18 show the brightness level stored in the driver, which
19 may not be the actual brightness (see actual_brightness).
22 What: /sys/class/backlight/<backlight>/actual_brightness
25 Contact: Richard Purdie <rpurdie@rpsys.net>
27 Show the actual brightness by querying the hardware.
30 What: /sys/class/backlight/<backlight>/max_brightness
33 Contact: Richard Purdie <rpurdie@rpsys.net>
35 Maximum brightness for <backlight>.
38 What: /sys/class/backlight/<backlight>/type
41 Contact: Matthew Garrett <mjg@redhat.com>
43 The type of interface controlled by <backlight>.
44 "firmware": The driver uses a standard firmware interface
45 "platform": The driver uses a platform-specific interface
46 "raw": The driver controls hardware registers directly
48 In the general case, when multiple backlight
49 interfaces are available for a single device, firmware
50 control should be preferred to platform control should
51 be preferred to raw control. Using a firmware
52 interface reduces the probability of confusion with
53 the hardware and the OS independently updating the
54 backlight state. Platform interfaces are mostly a
55 holdover from pre-standardisation of firmware