[Intel-gfx] [RFC] [intel-gfx] :The backlight issue when KMS is used
yakui.zhao at intel.com
Fri Apr 3 07:49:38 CEST 2009
When the kernel is booted with KMS enabled, the backlight brightness
can't be changed by xrandr tool. This issue is caused by that the native
kernel backlight I/F is not exposed to userland. In such case there is
no backlight property in xrandr tool. Of course the brightness can't be
controlled by xrandr tool.
If the native kernel backlight I/F is exposed to userland(ie. the
backlight property is hooked up by xrandr tool), the brightness will be
controlled by xrandr tool. But the inconsistency between ACPI backlight
I/F and xrandr tool appears.
>When it is changed by ACPI I/F, the xrandr can report the correct
>But if the brightness is changed by native kernel I/F, the ACPI I/F
will report the incorrect brightness. It is inconsistent and not what we
expected. Even when the ACPI opregion is used, the inconsistency still
In fact this inconsistency also exists in UMS mode if the backlight
control mode is legacy/native/combo. The issue is that the ACPI I/F
can't reflect the true brightness if the brightness is changed by xrandr
In UMS mode the ACPI I/F (kernel) mode will be preferred if there
exists the ACPI backlight I/F. Only when there is no ACPI I/F, it will
fall back to the other three modes.
How about following what we have done in UMS mode ?
a. When there exists the ACPI backlight I/F, the ACPI I/F will be
hook up in drmmode_display.c and exposed to xrandr tool. Then the
backlight can be changed by xrandr tool(the ACPI I/F is called). Of
course the backlight can also be changed by ACPI I/F. It is similar
with what we have done in UMS mode. Of course to eliminate the potential
inconsistency, the other three backlight control modes won't be exposed
b. If there is no ACPI backlight I/F, the native kernel backlight
property will be exposed. And then the backlight can be changed by
xrandr. (No ACPI I/F can control the brightness).
Welcome the comments.
More information about the Intel-gfx