Bug 492027 - Monitor does not turn on after automatic turn off
Summary: Monitor does not turn on after automatic turn off
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (other bugs)
Version First Reported In: 6.1.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: multiscreen
Depends on:
Blocks:
 
Reported: 2024-08-22 07:46 UTC by Gurenko Alex
Modified: 2024-12-17 15:17 UTC (History)
3 users (show)

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


Attachments
Screen Settings (220.86 KB, image/png)
2024-08-22 07:46 UTC, Gurenko Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gurenko Alex 2024-08-22 07:46:07 UTC
Created attachment 172846 [details]
Screen Settings

SUMMARY

I've been having a problem with "Turn off screen" feature after around Plasma 6.1 update. It was definitely working for me during the Plasma 6 beta time frame, I think it also works for 6.0.x. Now at 6.1.4 I still have a problem.

STEPS TO REPRODUCE
1. Enable Turn off screen and set it to 30 minutes and When locked: 1 minute
2. Lock the screen
3. Wait until the screen goes off and wait few more minutes
4. Move the mouse and/or press any button

OBSERVED RESULT

Screen does not turn on. Even more, if I force shutdown the PC and turn it on, screen still does not turn on, it requires a power cycle by unplugging it from the wall.

EXPECTED RESULT

Screen will turn on

SOFTWARE/OS VERSIONS:

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.6-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C84
System Version: 1.0

ADDITIONAL INFORMATION
In most cases, if I try to wake the screen *right after* it goes off, it turns back on right away, but after a few minutes it's 100% reproducible. I have Dell S2721dgfa monitor connected over DisplayPort cable, set to 165 Hz, it's a FreeSync Enabled screen with HDR support, I do have HDR set to off, I do have custom ICM profile applied, I do have 125% scaling enabled.
Comment 1 Nate Graham 2024-08-22 15:01:56 UTC
I can't reproduce this issue on current git master with the following system:
- All KDE software built from today's git master
- Screen turn-off time out on lock screen set to 10 seconds
- Lenovo ThinkPad X1 Yoga gen 4 with Intel UHD 630 iGPU
- Two screens tested:
-- 27" FHD screen connected via HDMI directly
-- 24" QHD screen connected via USB-C cable carrying a DisplayPort signal in alt mode

In both cases, the external screen woke up shortly after I wiggled my mouse.

Vlad and Xaver, what kind of debugging information should I ask for in circumstances like this? Could it actually be a monitor-specific issue?
Comment 2 Gurenko Alex 2024-08-31 13:02:50 UTC
So, it looks like it missed 6.2 release already, but can we still get the ball rolling here? I'm happy to provide additional information if you tell me what it is you need
Comment 3 Zamundaaa 2024-09-02 16:49:49 UTC
6.2 is not out yet, and neither is 6.1.5.

After waking up, is there anything suspicious in KWin's log? You can get it with
> journalctl --user-unit plasma-kwin_wayland --boot 0

Also, what's the output of drm_info when the screen doesn't turn on?
Comment 4 Gurenko Alex 2024-09-02 20:59:00 UTC
(In reply to Zamundaaa from comment #3)
> 6.2 is not out yet, and neither is 6.1.5.
> 
> After waking up, is there anything suspicious in KWin's log? You can get it
> with
> > journalctl --user-unit plasma-kwin_wayland --boot 0
> 
> Also, what's the output of drm_info when the screen doesn't turn on?

So, I've connected to the machine over ssh to monitor what's happening there and...not much...

I've captured two drm_info outputs, one before locking and one after the screen didn't wake up the only difference is one of the IDs changed:

```
$ diff ./drm-normal drm-failed 
882,883c882,883
<     │   │   ├───FB ID: 132
<     │   │   │   ├───Object ID: 132
---
>     │   │   ├───FB ID: 131
>     │   │   │   ├───Object ID: 131
914,915c914,915
<     │       ├───"FB_ID" (atomic): object framebuffer = 132
<     │       │   ├───Object ID: 132
---
>     │       ├───"FB_ID" (atomic): object framebuffer = 131
>     │       │   ├───Object ID: 131

```

the output of the journal:

```
Sep 02 20:04:34 wasp-blackquiet kscreenlocker_greet[23841]: Failed to write to the pipe: Bad file descriptor.
Sep 02 20:42:04 wasp-blackquiet kwin_wayland[2208]: kwin_screencast: PipeWire remote error:  connection error
Sep 02 20:42:05 wasp-blackquiet systemd[1892]: Stopping plasma-kwin_wayland.service - KDE Window Manager...
Sep 02 20:42:05 wasp-blackquiet kscreenlocker_greet[24155]: pam_unix(kde:auth): authentication failure; logname=agurenko uid=1000 euid=1000 tty= ruser= rh>
Sep 02 20:42:05 wasp-blackquiet kscreenlocker_greet[24155]: Failed to write to the pipe: Bad file descriptor.
Sep 02 20:42:05 wasp-blackquiet systemd[1892]: Stopped plasma-kwin_wayland.service - KDE Window Manager.
Sep 02 20:42:05 wasp-blackquiet systemd[1892]: plasma-kwin_wayland.service: Consumed 9min 41.236s CPU time.
```

The last record, looks like when I moved the mouse is:

> Sep 02 20:41:21 org_kde_powerdevil[2550]: dh=Display_Handle[i2c-6: fd=31], Keeping adjusted sleep multiplier 1.30 for SE_POST_WRITE or SE_POST_SAVE_SETTINGS

Otherwise, literally no records in the syslog
Comment 5 Zamundaaa 2024-09-03 21:39:36 UTC
Hmm, then it's not our bug I'm afraid - if the display was still off from KWin's perspective, the drm_info output would say so.
You might have better luck at https://gitlab.freedesktop.org/drm/amd/-/issues, but it sounds like it's a monitor issue and not caused by the video source. Maybe it goes into some deeper power state where you need to press a button on the monitor, or maybe something's more broken with it.
Comment 6 Gurenko Alex 2024-09-03 22:36:20 UTC
(In reply to Zamundaaa from comment #5)
> Hmm, then it's not our bug I'm afraid - if the display was still off from
> KWin's perspective, the drm_info output would say so.
> You might have better luck at
> https://gitlab.freedesktop.org/drm/amd/-/issues, but it sounds like it's a
> monitor issue and not caused by the video source. Maybe it goes into some
> deeper power state where you need to press a button on the monitor, or maybe
> something's more broken with it.

It was working perfectly fine between 6.0 beta 1 and 6.1 (not inclusive). I'll try opening issue for amdgpu, just in case, but I don't see why is it set to resolved now
Comment 7 Gurenko Alex 2024-09-04 11:19:33 UTC
For tracking purposes, I've opened issue upstream: https://gitlab.freedesktop.org/drm/amd/-/issues/3608
Comment 8 Gurenko Alex 2024-11-21 12:43:38 UTC
I have new information about this issue, I've upgraded my Wife's PC this week and ran a few test on with Fedora 41 and Fedora rawhide. She has a different GPU (nvidia 3070), different monitor (Benq sw270c) but same problem happened with her setup as well. After the default timeout screen went off and I couldn't wake it up afterwards, until the power cycle, so it's not AMD GPU specific.
Comment 9 Zamundaaa 2024-11-21 13:04:47 UTC
Please attach the drm_info output for the display working correctly, and for it not turning on again. Before, that determined beyond any doubt that KWin is turning it on again, and things goes wrong somewhere else.
Comment 10 Bug Janitor Service 2024-12-06 03:46:24 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Gurenko Alex 2024-12-17 09:39:56 UTC
I've been trying to reproduce the issue lately and luckily I cannot anymore. I have a feeling that's the 6.12 kernel and the rest of the software stack moved further along.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.5-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C84
System Version: 1.0

On my wife's PC I've captured this issue twice, drm_info showed card0 timeout both time for the nVidia card, so output captured, but now I cannot reproduce it too, I was testing it with 6.13.0-rc2, so looks like some fix made it into both 6.12.x and 6.13 rc2, but I'm speculating here.

I guess for now we can close it and hopefully it's fixed.
Comment 12 Nate Graham 2024-12-17 15:17:27 UTC
Awesome! Let's call it fixed then, until it happens again. If so, feel free to re-open the bug report. Thanks a lot for following up!