Bug 411050

Summary: graphical brightness control does not read actual_brightness before changing it
Product: [Plasma] plasmashell Reporter: Teddy <reportbug>
Component: Power management & brightnessAssignee: Plasma Bugs List <plasma-bugs>
Status: REOPENED ---    
Severity: normal CC: jpetso, nate, tinozzo123
Priority: NOR    
Version: 6.2.4   
Target Milestone: 1.0   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: example screenshot

Description Teddy 2019-08-18 23:58:44 UTC
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
Comment 1 Teddy 2019-08-19 00:01:42 UTC
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.
Comment 2 Teddy 2019-08-19 00:02:16 UTC
If I click Fn+Down the current brightness jumps from 45 to 95, it "continues" from 100.
Comment 3 Teddy 2019-08-19 00:22:08 UTC
Latest ubuntu 19.04 with plasma.
Comment 4 Nate Graham 2019-08-19 15:46:40 UTC
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%.
Comment 5 Teddy 2019-08-20 20:00:39 UTC
Alright, how can I personally test it?
Comment 6 Teddy 2019-08-20 20:02:18 UTC
I guess it's still not available in disco-proposed, I must compile it...
Comment 7 Teddy 2019-11-03 08:31:34 UTC
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
Comment 8 Teddy 2019-11-03 08:31:58 UTC
changed to 5.17.2
Comment 9 Martino Fontana 2022-06-21 08:26:50 UTC
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.
Comment 10 Jakob Petsovits 2024-05-20 03:06:42 UTC
(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.