SUMMARY If I change screen brightness using Fn+Up/Down, the progress bar on the toast icon matches the current level of brightness, but if it's modified by console, there can arise problems. STEPS TO REPRODUCE 1. Start your system with 100% brightness, Fn+Up will display a full progress bar 2. Change brightness from terminal like "echo 35 > /sys/class/backlight/nvidia_0/brightness". The screen will dim automatically 3. Now try to increase the brightness using the hotkeys, with Fn+Up. You will notice that the brightness doesn't increase and the progress bar is like at 100% OBSERVED RESULT KDE does not 'cat /sys/class/backlight/nvidia_0/actual_brightness' just before each brightness change request, but instead relies on what value it should have if I only had used hotkey. EXPECTED RESULT It should re-read the actual_brightness on each key combo, to see if there was a brightness change in-between. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 122237 [details] example screenshot The current brightness is 45 and can't be increased using Fn+Up keyboard key, also progress bar thinks the brightness is at its maximum (100), thus doesn't increase it anymore.
If I click Fn+Down the current brightness jumps from 45 to 95, it "continues" from 100.
Latest ubuntu 19.04 with plasma.
Cannot reproduce using git master (which will be Plasma 5.17). If I manually manipulate the brightness value with the command line, the OSD shows the correct level and does not jump back to 100%.
Alright, how can I personally test it?
I guess it's still not available in disco-proposed, I must compile it...
Still happening with plasma 5.17 backport on ubuntu 19.10 (ppa:kubuntu-ppa/backports). Operating System: Kubuntu 19.10 KDE Plasma Version: 5.17.2 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-19-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 8 GiB of RAM
changed to 5.17.2
I don't reproduce the issue on the screen brightness (I have an AMD GPU). But I do reproduce it on the keyboard backlight (`/sys/class/leds/platform::kbd_backlight/brightness`). Lenovo IdeaPad 5 14ARE05, Plasma 5.25.0.
(In reply to Martino Fontana from comment #9) > I don't reproduce the issue on the screen brightness (I have an AMD GPU). > But I do reproduce it on the keyboard backlight > (`/sys/class/leds/platform::kbd_backlight/brightness`). > Lenovo IdeaPad 5 14ARE05, Plasma 5.25.0. Devices in the Linux "backlight" subsystem can be monitored for changes. So we should always know the latest brightness of an internal laptop display. Devices in the "leds" subsystem - but also DDC/CI monitors - cannot be monitored. It would indeed be possible to perform an explicit read operation right before making any changes, but we'd have to be careful in avoiding bugs if this essentially blocking operation gets introduced into our existing keyboard brightness and/or display brightness code. It also introduces a little extra latency, so this would have to be limited to low-frequency operations like keyboard shortcuts, while applet slider changes need to remain write-only. Another not-great but potentially useful approach would be to do regular interval polling on devices without monitoring capabilities. The upside of that is getting updated values also in your brightness applet, without even trying to change it via keyboard shortcut first. Of course, the applet could also ask for an explicit read operation when it opens, so that the sliders adjust after just a fraction of a second after being opened. In general though, asking application-level code like the applet to issue manual read operations sucks, that's introducing extra complexity while the fix is still generally a buggy hack. Another perhaps more controversial approach would be to make users pick. Do you want Plasma to manage your devices, or do you want to pipe your own brightness values into the sysfs file? If there isn't a great solution without hacks, perhaps it's reasonable for Plasma to either own that brightness control without regard to external changes, or to ignore it entirely. Especially if the fix is as easy as "set the brightness again to reclaim full ownership". TL;DR: Cooperating with devices that make changes behind your back is hard and painful.