wingpanel-indicator-power
wingpanel-indicator-power copied to clipboard
Lag/Stutter while changing screen brightness with keys
I have a Dell Inspiron 3000 on which I installed elementary Juno a few days ago, alongside Windows 10. My experience has been smooth, but whenever I use the keyboard brightness keys to change the screen brightness, the brightness seems to stutter as it changes. It's always slow and laggy and sometimes it can take nearly 5 seconds after I press the key for the brightness to start changing, and if I keep either brightness key pressed the brightness pop up becomes unresponsive, the brightness doesn't change at all and the keyboard becomes unresponsive as well. This doesn't happen when I use the slider in System Setttings. I've used Windows 10, Manjaro with the i3 DE as well as Ubuntu on my laptop and never faced this problem before. I'm not sure if this is the right project to report this in, but it's seems relevant to the issue.
A quick Google search reveals that this seems to happen to many users with Dell laptops running Ubuntu, however in most cases the reason seems to be buggy ACPI and the solution is to disable the ACPI backlight driver with the acpi_backlight=vendor kernel parameter. However in my case ls /sys/class/backlight only lists intel_backlight and no ACPI driver, so my laptop's ACPI doesn't seem to be the issue. The kernel driver or the hardware is not the issue either because I tried "simulating" changing the backlight brightness from 0 to full with for i in seq 0 937; do echo $i > /sys/class/backlight/intel_backlight/brightness; sleep .001; done (937 is the value listed in intel_backlight/max_brightness) and this causes the brightness to increase smoothly with no stutter.
So it seems to be an issue with elementary, not the hardware. Looking into the power indicator's source reveals that elementary uses the gnome-settings-daemon so maybe gsd-media-keys or gsd-power is to blame?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
You only experience this issue with brightness? Does this also happen when you change volume for example? I'm afraid it's caused by the notifications, so everything that triggers a notification will trigger a short freeze. One existing issue on this: https://github.com/elementary/gala/issues/369
@peteruithoven Only with brightness. Sound controls work smoothly. I don't think its an issue with the notification system.
I attempted to track down the root cause by simulating the keypress using xdotool and here's what I observed.
When i simulated 20 individual key presses with for i in seq 1 20; do xdotool key XF86MonBrightnessDown; sleep .01; done the brightness went down smoothly, There's a slight lag for the pop up to appear, but it's not significant. However if I simulate a continuous key press with xdotool keydown XF86MonBrightnessDown although it goes down smoothly, the keyboard becomes unresponsive for some time, just like normal. I guess its not an issue withgnome-settings-daemon or any other power control system.
grep -e "input driver" /var/log/Xorg.0.log shows me that Xorg is using libinput for all input devices, so perhaps there is an issue with libinput, or the xf86-input-libinput driver, causing stuttering brightness key events. Maybe if I could increase the increments by which the brightness changes it would be less noticeable? Is there any way to do that?
journalctl logs.
PS: this happens only with Xorg. GNOME on Wayland works normally. Brightness changes without any delay or freeze.
Definitely not an issue with gnome-settings-daemon or anything that's controlling the brightness. I killed gsd-media-keys and obviously the brightness didn't change when I held down the brightness keys, but it still froze the system and made the keyboard completely unresponsive. I looked at the CPU usage and it goes crazy high. Should I open a new issue in elementary/os?
An observation...
On Loki, this wasn't so severe. It would still stutter when using the Fn+Brightness keys, but no longer than a second. On Juno, the whole UI becomes frozen when I press these keys.
Besides freezing the whole UI, instead of increasing/decreasing brightness one notch at a time, during the frozen state the brightness level will uncontrollably go up to 100% or 0% depending on which direction you intended to go.