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