https://bugs.kde.org/show_bug.cgi?id=486500
--- Comment #2 from Jakob Petsovits <jpe...@petsovits.com> --- (In reply to Nate Graham from comment #1) > Natalie or Jakob, is this one of those things that was fixed recently? I > cannot reproduce it. 6.0.4 is the very latest in brightness-related bugfixes at this time. I would assume that the reported issue is still present and reproduction circumstances are simply different. Let's see. Rounded up, a 23% brightness value is 30% of 75%. The dimming action uses 30%. So what we're looking at here is that the display was dimmed (likely before suspending) and doesn't get reset to its original value after waking up. I would be interested in the sequence of DPMS (screen turn-on) and brightness change operations. Mitja, could you follow the instructions of the PowerDevil README [1] to turn on verbose logs and then post the logs here? [1] https://invent.kde.org/plasma/powerdevil/-/blob/master/README.md My first guess would be that the DimDisplay and DPMS actions are both reacting to the system waking up, but they aren't coordinating and in this case the DimDisplay action goes first by setting the brightness. But the screen is still off and rejects the brightness change command. I don't know if this is actually what's happening, but it would seem plausible. If my theory is correct, a fix would involve coordinating both actions to make DPMS react to suspend events last and react to wake-up events first, so that DimDisplay can generally count on the screen being turned on when it sets the brightness. On a tangential note, I have some more patches in the works that should soon make it possible for us to remember brightness information across display remove+connect events, which might provide an indirect fix for the same issue but without action reordering. I need some more work to actually implement this, and it's also going to take a fair bit of reviewing effort by other developers to get there. -- You are receiving this mail because: You are watching all bug changes.
