SUMMARY Controlling the brightness of the monitor using ddcutil generally works but is wonky sometimes. (Due to the nature of ddcutil) it takes a short time until the monitor has adjusted the brightness (like half a second). Therefore, for example changing the brightness by scrolling on the brightness applet feels choppy as it seems it does a blocking wait until the monitor reported the changed brightness value. Also, when the monitor is dimmed to a lower brightness value and is powered off by Plasma because of no user input , it sometimes fails to reset to the previous brightness setting when waking up the monitor again. It just stays at the lowest brightness setting. STEPS TO REPRODUCE 1. Change brightness by scrolling on the brightness control bar icon/applet 2. It feels very choppy OBSERVED RESULT It feels very choppy EXPECTED RESULT The brightness target value should be overwritten immediately, with the actual monitor brightness following at a later point in time (when the ddcutil communication succeeded) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Kernel Version: 6.4.1-arch2-1 (64-bit)
(In reply to Derek Christ from comment #0) > SOFTWARE/OS VERSIONS > Operating System: Arch Linux > KDE Plasma Version: 5.27.6 > KDE Frameworks Version: 5.107.0 > Qt Version: 5.15.10 > Kernel Version: 6.4.1-arch2-1 (64-bit) I had already written up a paragraph about how the half-second delay is indeed intentional, but then I noticed that your bug report actually talks about the older Plasma 5.27 release which didn't even have an intentional delay for DDC brightness writes. Some work made it into Plasma 6.0 for reducing choppiness, and starting from 6.1 it's completely gone. > The brightness target value should be overwritten immediately, with the actual monitor brightness following at a later point in time (when the ddcutil communication succeeded) That's essentially how things work in recent releases, so I'll close this bug (as UNMAINTAINED because 5.27 won't get these updates anymore). I'll still include my original paragraph about Plasma 6 behavior below, for extra context. > Controlling the brightness of the monitor using ddcutil generally works but > is wonky sometimes. (Due to the nature of ddcutil) it takes a short time > until the monitor has adjusted the brightness (like half a second). > Therefore, for example changing the brightness by scrolling on the > brightness applet feels choppy as it seems it does a blocking wait until the > monitor reported the changed brightness value. The half-second delay is actually intentional behavior. DDC/CI commands will cause writes to the monitor's internal storage (EEPROM) and there is concern that for some monitors this storage will wear out over time when it's written to a lot. At which point the monitor would stop functioning. The half-second delay was introduced to minimize the amount of actual brightness changes that we need to send to the monitor, and matches the duration that Dell's Windows utility uses for the same purpose. I agree that the user experience could be better if we changed the brightness value immediately, but like everything this is a trade-off between different conflicting goals. > Also, when the monitor is dimmed to a lower brightness value and is powered > off by Plasma because of no user input , it sometimes fails to reset to the > previous brightness setting when waking up the monitor again. It just stays > at the lowest brightness setting. That's Bug 452492. Resolving this will take a bit more work, but we're closer to resolving it than half a year ago.