[Solved] Auto "Turn off screen" Power Management doesn't last

Physicist1616 · 2024-12-16 02:23:30

When the system goes to turn off the display to save power (currently set to "Turn off screen -> When locked: Immediately"), the display only stays off for about 90 seconds. It comes back on by itself without wiggling mice or pressing keys.

Looking at other threads, I'm seeing that amdgpu power features sometimes need a little tweaking, and looking at my logs, I'm seeing a lot of kscreen spam relating to displays and positioning.

sudo dmesg | tail output:

[96864.175804] amdgpu 0000:0a:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000000D SMN_C2PMSG_82:0x00000000
[96864.175808] amdgpu 0000:0a:00.0: amdgpu: Failed to retrieve enabled ppfeatures!
[97182.886757] amdgpu 0000:0a:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000000D SMN_C2PMSG_82:0x00000000
[97182.886764] amdgpu 0000:0a:00.0: amdgpu: Failed to retrieve enabled ppfeatures!
[97187.321335] amdgpu 0000:0a:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000000D SMN_C2PMSG_82:0x00000000
[97187.321341] amdgpu 0000:0a:00.0: amdgpu: Failed to retrieve enabled ppfeatures!
[100461.224081] amdgpu 0000:0a:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000000D SMN_C2PMSG_82:0x00000000
[100461.224089] amdgpu 0000:0a:00.0: amdgpu: Failed to retrieve enabled ppfeatures!
[100465.657814] amdgpu 0000:0a:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000000D SMN_C2PMSG_82:0x00000000
[100465.657818] amdgpu 0000:0a:00.0: amdgpu: Failed to retrieve enabled ppfeatures!

journalctl -b output (with `logger` commentary to timestamp when I'm locking the screen and when it came back up):
https://pastebin.com/sLkxrEY3

Additional details:
2 Acer displays with 1 LG 4k TV mirroring one monitor, not usually set to that input when these issues are occuring
0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (rev c1)
X11, Plasma
The issue has been occurring for quite some time, and I'm just getting around to troubleshooting it.

So my leading hypothesis at the moment is that all the kscreen spam is a red herring, and that the issue is amdgpu powersaving (but IDK about blindly trying the kernel boot flags I see in other posts, could work I guess); I'd love a second opinion.

Edit: Added [Solved] Subject tag to indicate we've got a kind-of workaround; seems like this is an upstream, known bug

Last edited by Physicist1616 (2024-12-19 18:22:00)

seth · 2024-12-16 15:19:29

xrandr -q > /tmp/randr.log
xset dpms force off
sleep 15
xrandr -q >> /tmp/randr.log
# wait until the outputs self-activate
xrandr -q >> /tmp/randr.log
cat /tmp/randr.log | curl -F 'file=@-' 0x0.st

Then try to disable kscreen ("kcmshell6 kded") - the theory would be that the output unregisters on DPMS, kscreen responds to that w/ reconfiguring the screen and that wakes the output.

Physicist1616 · 2024-12-17 01:30:11

Experimented with your instructions a little. Do I understand correctly you're trying to have that `sleep 15` end while the screens are still off? If so, that might need to be more like 5 or 7 seconds.

I made a decent script to produce the logs you're looking for and insert guide timestamps into both randr.log and journalctl. These logs are while I've got that sleep set at 5 seconds to try and catch one of those `xrandr -q`'s during the monitor-off period; let me know if that's not what you're intending.

/tmp/randr.log: http://0x0.st/XFdy.txt

journalctl --since='Dec 16 15:19:03': http://0x0.st/XFdg.txt

Also, I toggled the kscreen service a few times since last plasma restart while making sure I had good logs; let me know if that's likely to have impacted this test.

It doesn't look like disabling kscreen in "kcmshell6 kded" solved it.

seth · 2024-12-17 08:36:02

The xrandr configuration seems to remain stable, so also w/ your kded tests it's not kscreen that breaks the dpms (which however is the critical condition, you don't need to also lock the screen?)

Dec 16 15:22:56 arch user[161803]: stopped kscreen
Dec 16 15:23:01 arch user[161806]: Running xset dpms force off
…
Dec 16 15:23:23 arch user[161825]: Locking screen
Dec 16 15:23:25 arch systemd[874]: Created slice Slice /app/dbus-:1.2-org.kde.LogoutPrompt.
Dec 16 15:23:25 arch systemd[874]: Started dbus-:1.2-org.kde.LogoutPrompt@0.service.
Dec 16 15:23:26 arch systemd[874]: dbus-:1.2-org.kde.LogoutPrompt@0.service: Consumed 496ms CPU time, 72M memory peak.
Dec 16 15:23:27 arch kscreenlocker_greet[161877]: qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "en_US". Search paths QList("/usr/share/qt6/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/myspell/dicts")

Cause you're stopping kscreen, then DPMS off, then 22s later lock the screen and 2 seconds later you get a logout prompt and a virtual keyboard seems to show because of that!

Do you even need the latter, https://wiki.archlinux.org/title/KDE#Virtual_keyboard_2 ?

Physicist1616 · 2024-12-18 01:55:16

You're right, I don't need the virtual keyboard or particularly need the lock; it was my ghetto way of forcing the powersave to activate before your xset-dpms-foo.

$ sudo pacman -R qt6-virtualkeyboard
:: removing qt6-virtualkeyboard breaks dependency 'qt6-virtualkeyboard' required by plasma-workspace

I suppose I could just ignore the dependency check...

Today, casual observation suggests I was wrong that the kscreen disable didn't solve the problem. I'll test this more rigorously, including updates, reboots, and a fresh plasma session.

If disabling kscreen has indeed solved it, I can't help but feel a little nagged by the prompt in kcmshell6 that, if I've encountered a bug, it should be reported upstream. How do the KDE people respond to bug reports from upstart Arch users?

seth · 2024-12-18 08:25:25

https://bugs.kde.org/show_bug.cgi?id=471524
https://bugs.kde.org/show_bug.cgi?id=490533

Does it help to https://wiki.archlinux.org/title/KDE#Un … lution_set ?

Physicist1616 · 2024-12-19 18:19:18

Thanks for alleviating my conscience there!

Re: looking at the kscreen folder for invalid configurations, I see a bunch of redundant files there, none I eyeballed had obviously invalid resolutions though. There were so many it almost seems like there's a race condition where (my displays activating in every possible random order) * (each possible combination of displays I turn on) = (the total number of files in the directory).

Do I understand correctly that `rm -rf`ing the directory will just affect kscreen and I'll get a sane(ish) default to reconfigure to my liking? Regardless, whatever caused so many configs to generate I'm sure will continue and I'll just have to clean them out again eventually.

seth · 2024-12-19 18:39:20

Do I understand correctly that `rm -rf`ing the directory will just affect kscreen and I'll get a sane(ish) default to reconfigure to my liking?

Ideally, yes. Unideally kscreen will be broken and generate more weird stuff, but those are all cached layouts and the worst case scenario is that you'll have to re-arrange your preferred layout after the next login.

Arch Linux

#1 2024-12-16 02:23:30

[Solved] Auto "Turn off screen" Power Management doesn't last

#2 2024-12-16 15:19:29

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

#3 2024-12-17 01:30:11

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

#4 2024-12-17 08:36:02

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

#5 2024-12-18 01:55:16

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

#6 2024-12-18 08:25:25

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

#7 2024-12-19 18:19:18

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

#8 2024-12-19 18:39:20

Re: [Solved] Auto "Turn off screen" Power Management doesn't last

Board footer