SUMMARY Monitor brightness keeps constantly resetting back to 100% STEPS TO REPRODUCE 1. Turning monitor off and then on again 2. Just by launching some apps for example firefox 3. By having freesync enabled OBSERVED RESULT Brightness goes back to 100% with every monitor EXPECTED RESULT It should stay as that value i set it in OSD. Linux/KDE Plasma: KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.3 ADDITIONAL INFORMATION Anyways i have sensitive eyes so white backgrounds at 100% brightness almost get my eyes to watering. If this is some setting that can be changed then it should be in display configuration so it can be easily found
Managed to fix this issue by installing power-profiles-daemon from arch repo since it was missing from original plasma install now i can change brightness from taskbar. Still it might be better to let users decide between changing monitor brightness from plasma itself or monitor osd. So adding option in monitor configuration page would be ideal in my opinion
Did you not have powerdevil installed as well? I can't see how installing only power-profiles-daemon would have resolved this.
apparently i didnt have it installed i guess. When i installed arch i installed plasma-meta package but it still was missing power-profiles-daemon. My kde plasma basically let me know i was missing that package when i did some digging. After i installed that package i can set my monitor brightness from taskbar "brightness and color". I guess it defaulted to 100% when i was missing that package so it got resolved that way
KWin defaults the brightness of every monitor to 100% and that's a bug that I can confirm. It happens on session startup, monitor wake-up, and possibly other KWin output configuration change events, until the default brightness is changed. I have seen reports of this on Reddit and Lemmy. To reproduce: * Log out of Plasma * Delete the "brightness" property from your monitor entry in .config/kwinoutputconfig.json * Manually reduce hardware brightness for your display * Start a new Plasma Wayland session. KWin will ask PowerDevil to max out the brightness for any display without this entry, even if hardware brightness is currently lower than max. The power-profile-daemon installation seems like a red herring, because monitor brightness controls should be available with just PowerDevil by itself. (Without PowerDevil, hardware screen brightness would not be raised.) But the point is that the user needs to change the brightness default to get back to their previously configured monitor brightness, and they shouldn't have to do that. The bad news is that a fix will require an addition to plasma-wayland-protocols, plus matching patches in PowerDevil (to announce the initial monitor brightness) and KWin (to use it if it was announced). While I know that this can be done in a backwards-compatible way, I'm not sure if the existing guidelines around Wayland protocol versioning will allow me to make it so that PowerDevil will keep working with KWin from 6.2.0. That's a discussion topic for the merge review though.
I don't think this can be solved nicely... if your monitor resets its brightness on power off (which some do!), you really want KWin to ignore what it says. Can we somehow detect that the user actually used the OSD to change the brightness level? Or detect that the OSD is open when the brightness gets changed, and only accept the change then?
(In reply to Zamundaaa from comment #5) > Can we somehow detect that the user actually used the OSD to change the > brightness level? Or detect that the OSD is open when the brightness gets > changed, and only accept the change then? No. The best we can do is poll the monitor semi-regularly (perhaps every 30 seconds) and assume that any observed changes during the KWin session, while the monitor is on, were intentional. That's what the externalBrightnessChangeObserved signal within PowerDevil is meant to do, minus the polling part which is not currently being done for DDC/CI devices (but could be added).
I see this as well on ArchLinux without power-profiles-daemon. powerdevil is installed in version 6.2.0. I did not have this problem before version 6.2.0. Now I can set on my monitor's OSD whatever value I want, as soon as the dimming timeout configured in KDE's power saving settings is reached, or after wakeup from suspend, the monitor's brightness is always set to 100%, which hurts my eyes (just as with the OP). This only happens on my external monitor (BenQ PD2700U-B), which I use with my laptop's lid closed in a vertical stand (“clamshell” style).
Monitor brightness resets to 100% on every monitor wake-up. Software KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.7.0 Qt Version 6.7.2 Kernel Version 6.10.12-300.fc40.x84_64 (64-bit) Graphics Platform: Wayland Hardware Processors: 4 x Intel Core i5-4590 CPU @3.30GZ Memory 7.6 GiB RAM Graphics Processor: Mesa Intel HD Graphics 4600 Manufacturere: ASUS I upgraded to the latest KDE yesterday. The previous KDE version behaved a bit differently: on every monitor wake-up, the brightness reverted to the value that it had at the last system boot.
Huh...I did a few reboots and a factory reset of the monitor (Dell U3023E) and the problem seems to have gone away.
If using external monitor, workaround is to disable DCC/CI on monitor OSD.
I found that on both my Dell S2721DGF and my BenQ GW2480 that disabling DDC/CI worked for me. I don't like controlling my monitors via software anyways (except for some color correction), so that was the fix that works best for me. Might not be the best solution for those who like controlling their monitor's settings via software or who have no choice but control them via software (laptops being the primary example). Don't know if laptops are affected by this bug, but something worth pointing out.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6667
I have now installed `power-profiles-daemon'. This gets me a new widget for setting monitor brightness in my task bar, and if I use that one to set the brightness, the problem goes away.
Here the same problem. On arch linux. Although the "change brightness" option is disabled, after wakeup it is 100% and overrides my hardware setting on the monitor. For me it is weird that the monitor brightness control is in the power section AND that it is not available for all monitors independently.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/455
This is still a problem for me having two different calibrated monitors. All i need is to switch off the software brightness settings, but i fail to do so.
Git commit b799470e6edef0dd5e26bc6d7ae4d7c47ec64b50 by Jakob Petsovits. Committed on 18/12/2024 at 19:10. Pushed by jpetso into branch 'master'. Initially adopt current brightness of external brightness device This prevents KWin from amping up every display's brightness to 100% after a 6.2 update. Subsequent changes through a monitor's OSD menu or another software's DDC/CI commands are still ignored. Depends on an interface addition to external-brightness-v1 from plasma-wayland-protocols. Related: bug 494497 M +10 -0 src/backends/drm/drm_output.cpp M +2 -0 src/core/brightnessdevice.h M +18 -1 src/wayland/externalbrightness_v1.cpp M +4 -1 src/wayland/externalbrightness_v1.h M +1 -0 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/b799470e6edef0dd5e26bc6d7ae4d7c47ec64b50
Note that the fix (coming to 6.3.0) is for people who encounter this issue on a new setup without pre-existing KWin output configuration. For everyone in here for whom KWin/Wayland has already set brightness to 100%, please remember to use the Brightness and Color applet to permanently change your monitor brightness.
In the past, we did not have to use the Brightness and Color applet, we could just use our monitor's brightness controls and KDE would leave it alone. Is there a way to support that workflow?
(In reply to Tom from comment #19) > In the past, we did not have to use the Brightness and Color applet, we > could just use our monitor's brightness controls and KDE would leave it > alone. Is there a way to support that workflow? We have Bug 494497 still open to resolve that issue for Wayland. What's left to do on this front is code to manually read the current brightness from the monitor before making any change to it, so that we can restore brightness to the last configured level again later. As mentioned elsewhere (e.g. at https://discuss.kde.org/t/powerdevil-is-re-setting-my-display-brightness-after-the-display-wakes-up/23079/9), this is complicated by the fact that monitors don't send brightness change notifications to the OS but KWin has to get its brightness value from somewhere. It's doable to make it work without giving up on brightness control altogether. Still not quite there yet though. Imho the next step should be to add a checkbox to KWin's Display Configuration page in System Settings that specifically excludes a given display from brightness controls. That would go a long way for giving Wayland users a way out. On X11, Plasma 6.3 improves its behavior to avoid restoring the last known (but possibly wrong) brightness value after the monitor sleeps and wakes up again.
(In reply to Jakob Petsovits from comment #20) > Imho the next step should be to add a checkbox to KWin's Display > Configuration page in System Settings that specifically excludes a given > display from brightness controls. That would go a long way for giving > Wayland users a way out. That sounds great !
*** Bug 499034 has been marked as a duplicate of this bug. ***
If i may report: The behaviour has changed. Full brightness is only set on system startup. This would also be nice to be repaired.
Sorry to ruin the party, but this broke for me after installing 6.3. On 6.2 I wasn't having this problem. On Fedora 41 it uses tuned-ppd instead of power-profiles-daemon. Trying to install the ladder requires me to remove the former, so I'm not sure whats the right call here. The Monitor that I'm using is a GIGABYTE G24F. I don't see an option to disable DDC/CI on the OSD. It doesn't matter if I set it to 10% either on the Brightness and Color applet or on the monitor's OSD, it resets to 100% every time, expect on session startup. SOFTWARE Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.12.15-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland
Agree with RogueFort, this totally broke for me after 6.3 release. Until 6.2 I could change to HDR in system settings and then use the monitor's OSD to adjust the brightness which wouldn't change, but since 6.3, I can just change the brightness in the system settings that gets reset to 100% each time I turn on the monitor. This is a real pain, as I have an OLED monitor, and I don't like to leave it at 100% because of burn-in worries. Having to adjust each time is just bad. This either need to get fixed or have an option to go back to the old way until it's fixed. Jakob, is there a workaround for now? Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.3-cachyos1.fc41.x86_64 (64-bit)
Possible workaround for time being to get rid of issue is open /etc/environment with your favorite text editor "sudo nano /etc/environment" and add POWERDEVIL_NO_DDCUTIL=1 at the end of that file like this and then save and exit and reboot. You cant control brightness from plasma after that but atleast brightness stays at set percentage # # This file is parsed by pam_env module # # Syntax: simple "KEY=VAL" pairs on separate lines # POWERDEVIL_NO_DDCUTIL=1
(In reply to Tomi from comment #26) > Possible workaround for time being to get rid of issue is open > /etc/environment with your favorite text editor "sudo nano /etc/environment" > and add POWERDEVIL_NO_DDCUTIL=1 at the end of that file like this and then > save and exit and reboot. You cant control brightness from plasma after that > but atleast brightness stays at set percentage > > # > # This file is parsed by pam_env module > # > # Syntax: simple "KEY=VAL" pairs on separate lines > # > POWERDEVIL_NO_DDCUTIL=1 I confirm that this workaround fixes the issue. No more flash bang for yours truly.
(In reply to Tomi from comment #26) > Possible workaround for time being to get rid of issue is open > /etc/environment with your favorite text editor "sudo nano /etc/environment" > and add POWERDEVIL_NO_DDCUTIL=1 at the end of that file like this and then > save and exit and reboot. You cant control brightness from plasma after that > but atleast brightness stays at set percentage > > # > # This file is parsed by pam_env module > # > # Syntax: simple "KEY=VAL" pairs on separate lines > # > POWERDEVIL_NO_DDCUTIL=1 Thank you, will try that when I get home
> Jakob, is there a workaround for now? Apart from the "traditional" workaround mentioned in Comment #26, another workaround would be to upgrade to ddcutil 2.2.0 which was just released and is likely being tested by distributions right now. The new version has vastly improved display change detection and on most systems, should sidestep this issue for reasons I won't get into here. > This either need to get fixed or have an option to go back to the old way until it's fixed. Yes, this needs to be fixed. I've done some debugging but need to put in more work to understand why exactly this is happening. Also see Bug 500116 Comment #6, honestly there are a bunch of bug reports right now and I'll need to have a look later to see which of these are all caused by the same underlying issue.
Thanks Jakob, I didn't mean to be rude or anything. Really appreciate the work done here. As for testing ddcutil 2.2.0, I downloaded the copr package, reboot the system but no improvements, it still resets to 100% each time I turn on the monitor. Only the workaround from comment #26 for me, I'll be using it until a proper fix is deployed. Is there a unique identifier for the connected monitor? Maybe KDE could persist the state after each change, so that it can then restore it if the monitor is connected/turned after it's turned off/disconnected.
(In reply to Gustavo from comment #30) > Thanks Jakob, I didn't mean to be rude or anything. Really appreciate the > work done here. Thanks. I wasn't reading any rudeness; if anything, I am more concerned about making others feel bad (e.g. by missing bugs that don't get fixed fast enough). > Is there a unique identifier for the connected monitor? Maybe KDE could > persist the state after each change, so that it can then restore it if the > monitor is connected/turned after it's turned off/disconnected. There is such an identifier, and what you're suggesting is what we're doing right now (at least on Wayland). Which is why it's weird that KWin would then ignore this brightness value that it has itself stored earlier, and asks for 100% brightness instead. I'm sure there is a good explanation for why this is happening and how it can be fixed, I just haven't found it yet.
I can confirm that ddcutil 2.2.0 fixed issue for me atleast. Brightness stays at 35% where i have set it.
(In reply to Tomi from comment #32) > I can confirm that ddcutil 2.2.0 fixed issue for me atleast. Brightness > stays at 35% where i have set it. Weird, for me it didn't work, I installed it and reboot the system. After that, I changed the brightness value in settings to something else other than 100% and then turned off the monitor and turned back on. It then goes back to 100%
For me atleast both monitors are BenQ. Primary screen in Benq XL2540K and secondary screen is BenQ XL2411Z. Primary monitor is connected with displayport second screen is connected with club3d displayport to active dvi-dual link adapter. Primary monitor is running on 240 hz and freesync is enabled. Second monitor runs at 144 hz. Operating System: CachyOS Linux KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.4-2-cachyos (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 9700X 8-Core Processor Memory: 31.0 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XT
My Pixio PX275h monitors connected via DP have the same issue on Wayland, but everything is fine on X11.
Thats strange ! On Archlinux; Wayland; (Colormanagement installed) it works fine since 6.3. Can this be Moitor dependend ? I use a LG 33UN880.
After many reports here of it working after updating to ddcutil 2.2, I tried again, to see if I've done something wrong but no luck. It still doesn't work correctly for me when turning monitor on and off. It does keep the brightness if I reboot the system keeping the monitor on though. ddcutil screenshot: https://i.imgur.com/3DmWrOX.png Video of the problem occuring: https://streamable.com/lxuc2o
apparently my bug report went missing, but yes, I reiterate, and support all of the above, apparently at least w/multi monitors plasma 6.3 borked wake from sleep, monitor sleep/power off in that when woken it defaults to 100% brightness rather than the settings value! This is VERY annoying! And no there is no good workaround! How this was missed in testing before release is beyond me! Only things I can add is that PERHAPS it is multi monitor related as ONLY my PRIMARY monitor gets set to blisteringly bright 100% brightness meanwhile my secondary happily chugs along at its set brightness value! I tried my fw13 i7-1165G7 by closing the lid for a few minutes and it did NOT exhibit the bug on wake from 'sleep' (not sure if it slept, but that's linux for you...). I did NOT test it by EXPLICITLY pu7tting it to sleep, which I think that I will do so now! This is such a major usability problem that it shopuld have very high priority to have the changes that caused this bug reverted ASAP! until said changes can be implemented w/o causing this problem. And yes yes I know volunteers, etc, but I did contribute, well a gvery small amount at this time(funds) but, yes Im not asking because I contributed but because this is a very bad usability bug that should just be reverted until a real fix can be put in place! My primary monitor # 100% is blindingly bright to me!
Try workaround i mentioned in https://bugs.kde.org/show_bug.cgi?id=494408#c26 it works unless you need to constantly switch brightness. Sometimes bugs just get missed like this is probably setup sensitive stuff. ddcutil 2.2.0 fixed issue for my setup but for example it doesn't work with Gustavo's setup. I just have hunch this issue is monitor related like it "forgets" monitor when you shut it down and when you turn it on again it defaults to 100% brightness because it thinks its new monitor or something like that.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7231
Git commit 17e85d7ae4adde142afa5d267c41cca2b449460d by Xaver Hugl. Committed on 25/02/2025 at 14:49. Pushed by zamundaaa into branch 'master'. workspace: don't set brightness to the display value on every startup It should only be set the first time the brightness device is detected. It should also be set to the brightness of the device, and not of the output, which is always 1.0 after the output is connected. M +4 -3 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/17e85d7ae4adde142afa5d267c41cca2b449460d
Git commit 2b761418f6610495263ad5cf6c61e2ad7f68e167 by Xaver Hugl. Committed on 25/02/2025 at 15:54. Pushed by zamundaaa into branch 'Plasma/6.3'. workspace: don't set brightness to the display value on every startup It should only be set the first time the brightness device is detected. It should also be set to the brightness of the device, and not of the output, which is always 1.0 after the output is connected. (cherry picked from commit 17e85d7ae4adde142afa5d267c41cca2b449460d) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +4 -3 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/2b761418f6610495263ad5cf6c61e2ad7f68e167
Thanks Xaver & Jakob
Looks like the fix just about made it into Plasma 6.3.2 today, rather than only 6.3.3 two weeks later.
*** Bug 500116 has been marked as a duplicate of this bug. ***
*** Bug 500609 has been marked as a duplicate of this bug. ***
*** Bug 495109 has been marked as a duplicate of this bug. ***
I can confirm that 6.3.2 fixes the issue for me. Thank you everyone
6.3.2 fixes it for me!
*** Bug 414502 has been marked as a duplicate of this bug. ***