Bug 352442

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.