ROSA Linux Bugzilla – Bug 4844
Delay of brightness change by function keys on Dell notebook
Last modified: 2015-03-22 00:46:06 MSK
Description of problem:
If I press Fn+Up (increase brightness) or Fn+Down (decrease brightness) functional keys then the brightness will be changed with a 80 seconds delay. If I press one of these key combinations multiple times then system hangs for several minutes.
Appropriate X events for Fn+Up and Fn+Down in xev output are displayed with the same delay.
PC probe (Dell Latitude E6530): http://hw.rosalinux.ru/index.php?probe=f432cce700
Version-Release number of selected component (if applicable):
R5 KDE x86_64
Linux kernel: 3.14.25
How reproducible: always
Created attachment 3592 [details]
Fn+Down X events
Created attachment 3593 [details]
Fn+Up X events
The problem persists with kernel-nrj-desktop-3.17.7-1rosa: the brightness cannot be changed at all by functional keys.
PC probe: http://hw.rosalinux.ru/index.php?probe=9ee4eb2eab
Created attachment 3598 [details]
brightness doesn't change at all on kernel 3.17.7
With these additional kernel boot options I can change display brightness in the tray applet:
Also brightness media keys begin to work well after sleep of the PC.
HW probe after sleep: http://hw.rosalinux.ru/index.php?probe=c70ff3ca5a
Similar situataion at Dell Precision M4800. But switching brightness delay not so big. If I switch brigthness down, delay is bigger (about 10-15 sec sometimes). If up — 2-3 seconds.
hwprobe after pressing Fn+Brightness key: http://hw.rosalinux.ru/index.php?probe=802d03d867
For Dell Precision M4800, 'acpi_backlight=vendor' boot option solved the problem.
The things are different on Dell Latitude E6530.
Might be ACPI-related. There are many changes in that area in the mainline kernel that 3.14 branch does not have yet. I'll try to adapt some of these for 3.14, then we'll see.
Meanwhile, please check if the problem still shows up on Dell Latitude with kernel 3.18.x (http://abf-downloads.rosalinux.ru/kernels_3_18x_personal/repository/rosa2014.1/x86_64/main/release/) and 'acpi_backlight=vendor' boot option alone.
No 'video.use_native_backlight', no 'acpi_osi', no 'video.brightness_switch_enabled'.
A note about kernel 3.18. Use it with free graphics drivers at the moment. The proprietary ones are still poorly supported there.
Seems that the new kernel 3.18 with acpi_backlight=vendor additional option fixed the problem in general.
Now I can use both functional keys and tray widget to change brightness up and down.
HW probe (Dell E6530 + R5 + Kernel 3.18): http://hw.rosalinux.ru/index.php?probe=2f2a947ba8
But the problem returns after the system tries to decrease/increase brightness automatically (on idle or on first mouse input, for example).
HW probe after automatic brightness change: http://hw.rosalinux.ru/index.php?probe=13592ff944
(In reply to comment #9)
> Seems that the new kernel 3.18 with acpi_backlight=vendor additional option
> fixed the problem in general.
Might, indeed, be ACPI-related then.
So, as a first step, I'll check, which patches to that subsystem we do not yet have in kernel 3.14 and will try to add them.
Fn+Up and Fn+Down brightness keys and tray applet also don't work on Acer Aspire V3-571G. But system doesn't hang.
HW probe: http://hw.rosalinux.ru/index.php?probe=70b1601c4c
The acpi_backlight=vendor option fixed applet only.
Please remove dkms-vboxadditions and virtualbox-guest-additions, reboot the system (boot to kernel 3.14.33) and see if the problems is still there.
Unfortunately, this doesn't solve the issue.
The delay is the same and the system hangs when trying to change brightness by Fn+Up and Fn+Down keys. Also I can't change brightness in the tray widget.
HW probe: http://hw.rosalinux.ru/index.php?probe=f888b99936