https://bugs.kde.org/show_bug.cgi?id=513809
Rusty <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #19 from Rusty <[email protected]> --- Still reproducible on Plasma/KWin/PowerDevil **6.7.4** (Fedora 44, Wayland, NVIDIA proprietary, three monitors), so the fix in 6.6.5 did not resolve this. Two details in my case differ from the existing reports and I think they narrow the cause. **1. No suspend was involved.** The screen stayed dimmed indefinitely while I was actively using the machine — continuous keyboard and mouse input never undimmed it. That makes the `KIdleTime::catchNextResumeEvent()` theory in MR !613 an unlikely explanation for this instance. The trigger here was restarting PowerDevil while a dim was applied (I restarted `plasma-powerdevil.service` with `POWERDEVIL_NO_DDCUTIL=1` set, while the display was idle-dimmed). **2. It is the KWin software-dimming path, not DDC.** One output only: ``` $ kscreen-doctor -o Output: 2 DP-1 ... Brightness control: supported, set to 100% and dimming to 30% ``` The other two outputs report `Brightness control: unsupported`. DP-1 is the only one with `"allowSdrSoftwareBrightness": true` in `~/.config/kwinoutputconfig.json`, which is what gives it `Capability::BrightnessControl` via `drm_output.cpp:233`. The monitor's own hardware brightness (DDC VCP 0x10) read 100/100 throughout, so the panel was never touched — consistent with `DrmOutput::updateBrightness()` deliberately keeping dimming in software. **What did not clear it:** - `systemctl --user restart plasma-powerdevil.service` (twice) - `kscreen-doctor --dpms off` then `--dpms on` - `kscreen-doctor output.DP-1.brightness.99` then `.brightness.100` **What did clear it instantly** (dimming back to 100%): ``` busctl --user call org.kde.ScreenBrightness /org/kde/ScreenBrightness/display0 \ org.kde.ScreenBrightness.Display SetBrightness iu 7000 0 busctl --user call org.kde.ScreenBrightness /org/kde/ScreenBrightness/display0 \ org.kde.ScreenBrightness.Display SetBrightness iu 10000 0 ``` `kscreen-doctor output.DP-1.dimming.100` also works as a workaround. **Why commit be28578d ("Fix screen brightness stuck at 30% after PowerDevil restart") looks incomplete.** It changed the constructor to `m_desiredDimming(1.0)` (`daemon/controllers/kwinbrightness.cpp:137`), but nothing then *writes* that 1.0 to KWin at startup. The only write is `m_output->setDimming(m_desiredDimming)` in `applyPendingBrightness()` (`kwinbrightness.cpp:198`), reachable only via `scheduleSetConfig()`. `setDimmingMultiplier()` early-returns on equality (`kwinbrightness.cpp:216-218`), so when `DimDisplay` later calls `setDimmingRatio(DIMMING_ID, 1.0)` the value already matches locally and no config push happens. Meanwhile KWin still holds `dimming = 0.3`: that state is in-memory only in `BackendOutput::State::dimming`, is never serialized to `kwinoutputconfig.json`, and KWin has no path that resets it when the brightness client disconnects. `DimDisplay::m_dimmed` also defaults to `false` after a restart, so the guard at `dimdisplay.cpp:41-43` short-circuits the restore before it reaches the controller. So PowerDevil's cache and KWin's actual state desynchronize, and the equality guard means they can never resynchronize. `SetBrightness` fixes it only incidentally, because `applyPendingBrightness()` pushes brightness and dimming together and `setBrightness()` has no equality guard. There is a second, non-restart route to the same desync: when `KWinDisplayDetector::checkOutputs()` re-creates a `KWinDisplayBrightness` (`kwinbrightness.cpp:84-87`), the replacement starts at 1.0, and the only code that would re-push the active ratio (`screenbrightnesscontroller.cpp:221-223`) sits behind the `readded` branch, which requires an `m_rememberedDisplayState` entry — and that map is populated only in the `else` branch at `:506-512`, i.e. only for displays that do *not* support a dimming multiplier. KWin displays always do, so that re-push is unreachable for them. MR !654 looks like it addresses exactly this (reconciling stale dimming on init, plus migrating the ratio across display-map rebuilds). Alternatively, having the constructor or PowerDevil startup unconditionally *write* `dimming = 1.0` rather than merely assume it would close the restart path on its own. -- You are receiving this mail because: You are watching all bug changes.
