https://bugzilla.kernel.org/show_bug.cgi?id=54261
Summary: backlight: setting backlight level don't always work
on HP Compaq 6735s
Product: ACPI
Version: 2.5
Kernel Version: 3.2.35
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ACPICA-Core
AssignedTo: acpi_acpica-c...@kernel-bugs.osdl.org
ReportedBy: ldx...@gmail.com
Regression: Yes
When I want to change the backlight level, I use the command:
echo -n [level] > /sys/class/backlight/acpi_video0/brightness
But the actual backlight level often does not change, if I run this command
several times, it will works, but only after a certain time (so 10 times the
commands in 3 seconds does not work better than 4 in 3 seconds)
Reading the 'actual_brightness' can sometimes change the actual brightness
(according to the last value written in 'brightness').
Expecting result: the actual real backlight level change when writting to
'/sys/class/backlight/acpi_video0/brightness'
This bug can cause the kernel to disable backlight management when it check if
the _BQC acpi method return an index (2 to 13 or something like that) or a
level (0 to 100).
When this bug occur at boot time, the kernel do that:
set the backlight level to max, ie 100
get the backlight level, at this time, the real backlight level can change to
the lowest level (for me it's 30) and the function that retrieve the result of
the _BQC method return 30.
The kernel compare levels and as 30 != 100, assume the returned value is an
index.
Then the kernel tries to set the level to a invalid value and cause the
backlight management to be disabled.
When the backlight management is disabled, there is nothing in the
/sys/class/backlight folder.
The code doing that is in drivers/acpi/video.c when executing:
result = acpi_video_device_lcd_set_level(device, max_level);
[...]
result = acpi_video_device_lcd_get_level_current(device, &level, 0);
[...]
br->flags._BQC_use_index = (level == max_level ? 0 : 1);
[...]
level = br->levels[level_old]; <-- at this time, level_old is not in the
range of the array as it's > 30, thus reading an invalid value (but does not
crash)
I tested several kernel version and discovered that this bug occur at least
since kernel version 2.6.38. Kernel 2.6.34.14 works fine, the backlight is
working as expected.
2.6.35 and 2.6.37.6 is hanging at boot, when populating /dev.
3.7 does not work, same problem as stated here.
When the kernel 2.6.35 or 2.6.37.6 is hanging, after some times (or because I
pressed the power button ?), udev tries to kill modprobe processes (but can't).
ACPI is mentionned in something like 'ACPI0001'. This hang already occured for
the newer kernel (>2.6.38) but I can't at this time say if it's from the same
cause.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
