Bug 494233 - Unable to control second screen brightness after some time
Summary: Unable to control second screen brightness after some time
Status: RESOLVED FIXED
Alias: None
Product: Powerdevil
Classification: Plasma
Component: general (show other bugs)
Version: 6.1.5
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-07 08:30 UTC by d3vilguard
Modified: 2024-10-21 06:56 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description d3vilguard 2024-10-07 08:30:59 UTC
SUMMARY
Upon boot I'm able to change the brightness of my two monitors but after some time plasma is unable to control the brightness of the second screen

Issue:
Plasma will boot being able to control the brightness of the two screens. After a while plasma looses the ability to control the brightness of the display on DP2, while having no problem connecting DP1. Sleep is disabled, only screens turning off is enabled.

Since the feature was introduced in 6.0 I had no bugs with controlling the brightness on both screens. Along 6.1 it started to have the described issue.

I can confirm that DDCUTIl has no problem controlling the brightness of the two screens when plasma starts to be unable. I can also confirm that the IDs for the monitors/outputs in DDCUTIL stay static. Meaning that the back-end for screen control being DDCUTIL is more than fine. Powerdevil on the other hand seems to be the culprit. 

OBSERVED RESULT
Plasma looses control over second screen brightness after some time.

EXPECTED RESULT
Like in plasma 6.0, plasma should always be able to control both screens brightness.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch KDE Wayland 
KDE Plasma Version: 6.1.5 (prior 6.1 was not OK also)
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.3

ADDITIONAL INFORMATION

Hadrware:
Desktop!
GPU: AMD 6800
Display 1 is connected on DP-1 (for the card that is the primary display) (ACER XF243Y P)
Display 2 is connected to DP-2 (Huawei SSN-24)
Comment 1 Natalie Clarius 2024-10-08 01:15:11 UTC
I've encountered this as well today, haven't yet figured out under what condition this happens.
Comment 2 d3vilguard 2024-10-11 04:13:53 UTC
(In reply to Natalie Clarius from comment #1)
> I've encountered this as well today, haven't yet figured out under what
> condition this happens.

while having no problem controlling*** DP1 (typo)

6.2 seems to be ok for now.
Comment 3 d3vilguard 2024-10-11 18:45:44 UTC
I think I found it. So this mainly happened if I leave the PC on for the night or prolonged time. Screens will turn off (set by plasma to do so). Now on 6.2 you have a sound when a monitor is connected. When I move my mouse my huawei wakes fast (and never had problems with lost control), my acer on the other hand takes a few more moments. Well, when the ACER strarts, plasma plays the sound for a connected device. I think my initial thought that plasma might be thinking that the monitor is not connected at all might be right. 6.2 seems fine. Will report in a few hours after I leave the PC for the night. After that it's the devs decision here on what to do with the bug.
Comment 4 d3vilguard 2024-10-12 14:34:40 UTC
6.2 is even worse. After some time it will have "some" control over the screen which 6.1 lost control over. It either applies a software dim leading to the screen being.. dim, or it gets a brightness scale that is completely off. 100% in plasma will be sub 30% for the monitor.
Comment 5 d3vilguard 2024-10-13 04:27:40 UTC
(In reply to Natalie Clarius from comment #1)
> I've encountered this as well today, haven't yet figured out under what
> condition this happens.

final update
6.2 is affected too. Issue occurs if I leave the monitors off for at least a few hours (set in power menu to turn off after 20 minutes automatically).

CURRENT BEHAVIOR:
 - 6.2 will be able to control monitor brightness but now the monitor (ACER) that it looses control over is dim. There is some level of brightness control but the monitor is visually very dim, compared to the monitor that plasma has no problems with.
- removing powerdevil (for testing) leads to both monitors being dim after a reboot. This led me to the conclusion that powerdevil after some time looses control over one of the monitors. In 6.1 it lost full control, in 6.2 in seems to be partial (due to the some level of brightness control, yet being very dim).
- Restarting powerdevil fixes the issue (fixing as in temporary untill it reoccurs):
systemctl --user restart plasma-powerdevil.service

Video with the latest findings: https://www.youtube.com/watch?v=sV6BkxrI1Gg
Video doesn't show me playing around with monitor brightness. Dim/ACER monitor will get a bit brighter but still will be very dim. Restarting powerdevil, like shown in the video, fixes that.
p.s. sorry for the other messages here. Was trying to keep notes of my findings for myself included.
Comment 6 Tomasz Hołubowicz 2024-10-13 16:48:22 UTC
I experience the same issue. After a while external screen becomes dim and although I can still control its brightness with a widget, it is much dimmer than usual. I couldn't find a way to revert brightness so thanks a lot d3vilguard! Your workaround with systemctl --user restart plasma-powerdevil.service at least temporary helps.
Comment 7 d3vilguard 2024-10-17 12:05:39 UTC
This is still present in 6.2.1.
Loosing control over second screen after time and second screen getting dim.
I also noticed that plasma splash will be dim on both screens until powerdevil loads and undims it (right before transitioning to the desktop).
Comment 8 d3vilguard 2024-10-21 06:56:17 UTC
(In reply to Tomasz Hołubowicz from comment #6)
> I experience the same issue. After a while external screen becomes dim and
> although I can still control its brightness with a widget, it is much dimmer
> than usual. I couldn't find a way to revert brightness so thanks a lot
> d3vilguard! Your workaround with systemctl --user restart
> plasma-powerdevil.service at least temporary helps.

can you test 6.2.1? Extensive testing has not led to the issue reproducing after updating.