When I press brightness hotkey, brightness updates instantly and OSD pops up as expected. But when I press it again in a short time, it either ignores me or reacts few seconds after (by showing me OSD and actually changing brightness). Same if I hold the hotkey: it reacts after few seconds of holding the hotkey. Please tell me if you need additional information. Reproducible: Always - Changing from battery applet is instant without any delays. - Holding volume keys for KMix works as expected. - This might be related to bug 345208 (e.g. its reporter was not holding key long enough)
Thanks for report. *** This bug has been marked as a duplicate of bug 350676 ***
I don't agree it is duplicate of bug 350676. It works even after single keypress, but its response to second keypress is either slow or none. Also it is the same for both brightness increase and decrease.
Can you check if there's any process running at 100% cpu right after you press the brightness key? Or perhaps if plasma is frozen (try moving your mouse over taskbar and see if there's any change)? Also, can you please open Konsole and run this: $ killall kded5 && kded5 & now change brightness, what is the output on Konsole?
(In reply to Martin Klapetek from comment #3) > Can you check if there's any process running at 100% cpu right after you > press the brightness key? Or perhaps if plasma is frozen (try moving your > mouse over taskbar and see if there's any change)? Nope, there aren't any; and plasma keeps running (popups pops up, start menu launches) > Also, can you please open Konsole and run this: > > $ killall kded5 && kded5 & > > now change brightness, what is the output on Konsole? It gives me a lot of messages like: powerdevil: Screen brightness value: 609 powerdevil: Screen brightness value max: 937 powerdevil: set screen brightness value: 656 powerdevil: Screen brightness value: 609 powerdevil: Screen brightness value max: 937 powerdevil: Screen brightness value: 656 powerdevil: Brightness changed!! powerdevil: Screen brightness value max: 937 powerdevil: Screen brightness value: 656 powerdevil: Screen brightness value max: 937 powerdevil: set screen brightness value: 703 but it writes it not on keypress but on actual brightness change (i.e. after some time after keypress)
Okay, seems like it is an upstream (e.g kernel/ACPI) bug: even in "showkey --scancodes" it appears after a delay; and also "cat /sys/class/backlight/intel_backlight/brightness" hangs at the same time.
Thanks for reporting back, closing as upstream bug.
I tired to bind the key with some random key other than brightness up/down. Probably the brightness is being adjusted by hardware when such key is pressed but the key event is also being sent at the same time. But at this time, I notice that 350676 is still there. Probably there are more than one issues here.
(In reply to Weng Xuetian from comment #7) > I tired to bind the key with some random key other than brightness up/down. > Probably the brightness is being adjusted by hardware when such key is > pressed but the key event is also being sent at the same time. > > But at this time, I notice that 350676 is still there. Probably there are > more than one issues here. Thanks! That workaround indeed worked! If I use non-hardware keys for brightness control, it just works (almost) without any delay.
@Igor: Do you have a link to the upstream issue? Is there a bug report at all?
(In reply to Kevin Funk from comment #9) > @Igor: Do you have a link to the upstream issue? Is there a bug report at > all? I didn't report anything myself, and not sure if there is relevant bug report there. Although I've seen almost same problems on various forums (https://ask.fedoraproject.org/en/question/69033/slow-response-on-brightness-control-lenovo-u330p/, http://ubuntuforums.org/showthread.php?t=2208278), some old bugs in launchpad and kernel bugzilla (https://github.com/linuxmint/cinnamon-settings-daemon/issues/17, https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/847001, https://bugzilla.kernel.org/show_bug.cgi?id=63931); bust most of them are market as closed. But there are also a lot of workarounds (various kernel options, X configurations, kernel, etc), but neither of them worked for me.
Had the same problem on my Asus Zenbook, but the "acpi_backlight=vendor" kernel command line parameter helped for me.