| Summary: | Screen remains dimmed after wake-up | ||
|---|---|---|---|
| Product: | [Plasma] Powerdevil | Reporter: | Mitja <mtjhrj> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | daltonminer, jpetso, me, natalie_clarius, nate, postix |
| Priority: | NOR | ||
| Version: | 6.0.4 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=482278 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Journalctl logs
powerdevil logs Logs file Logs |
||
|
Description
Mitja
2024-05-03 12:34:26 UTC
Natalie or Jakob, is this one of those things that was fixed recently? I cannot reproduce it. (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. Created attachment 169176 [details]
Journalctl logs
Here are the logs. I would like to note, that the reduction is higher than 30%, because the brightness setting is reduced from 75% to 23%. This makes a reduction of a 70%. Created attachment 169177 [details]
powerdevil logs
These are logs related only to powerdevil events (journalctl --boot | grep -i "powerdevil"). The logs were collected the following way: 1. At 10:10 I turned on the computer and login to desktop 2. Left the computer inactive to make it enter in standby. 3. Recovery from standby and collection of logs started at around 10:34:50 Thanks. These are only regular logs, not verbose - did I make a mistake in the README instructions for setting the QT_LOGGING_RULES environment variable? Please double-check that this was set and powerdevil was restarted.
The main thing we can learn from these logs is this line:
> org.kde.powerdevil: [DDCutilDisplay]: ddca_set_non_table_vcp_value -3023
Which basically tells us that setting the brightness via DDC/CI failed. According to the libddcutil source code, this result is DDCRC_VERIFY, described as "read after VCP write failed or wrong value". I.e. the monitor was present to communicate with the system and accepted the command, but ignored it so the brightness was still unchanged.
I think the theory is still the same. I'd still be interested in more detailed powerdevil logs.
(In reply to Mitja from comment #4) > Here are the logs. I would like to note, that the reduction is higher than 30%, because > the brightness setting is reduced from 75% to 23%. This makes a reduction of a 70%. Sorry, yes. I should have been clear to say that the dimming action reduces brightness *to* 30% of the original value, not *by* 30%. So a reduction by 70% is expected (we just need to raise it back up after standby). This looks close enough to Bug 482278 to call both reports duplicates of each other. Let's continue at the other bug, as it has been around for longer with more participants (although this one has more useful info so far). *** This bug has been marked as a duplicate of bug 482278 *** Actually no, let me un-duplicate this again because Bug 482278 is about brightness being dimmed after *unlocking*, whereas this bug is about brightness being dimmed immediately after wake-up (i.e. brightness would be wrong even on the lock screen). Sorry about that. Created attachment 169193 [details]
Logs file
The logs were collected the following way: 1. Run the command systemctl --user edit plasma-powerdevil.service 2. Added line Environment="QT_LOGGING_RULES=org.kde.powerdevil=true" under [Section] 3. Saved the file. The following message was shown: Successfully installed edited file '/home/mitja/.config/systemd/user/plasma-powerdevil.service.d/override.conf'. 4. Left computer inactive for about 40 minutes. 5. Resumed from Standby and collected logs using command journalctl --boot > /home/mitja/Dokumenti/JournalBootLogs2.txt and uploaded file. (In reply to Mitja from comment #12) > 1. Run the command systemctl --user edit plasma-powerdevil.service > 2. Added line Environment="QT_LOGGING_RULES=org.kde.powerdevil=true" under [Section] Did you mean [Service] rather than [Section]? If it's indeed [Section], then that's why it's not working. Its Service. My mistake. (In reply to Mitja from comment #14) > Its Service. My mistake. Then I don't know. The only thing that's missing from your description is restarting the PowerDevil service so the saved file takes effect: > systemctl --user restart plasma-powerdevil.service If you've done that, it should have printed more logs already. Created attachment 169238 [details]
Logs
Hope this time works.
*** This bug has been marked as a duplicate of bug 452492 *** |