Bug 496631 - External Monitor not waking up properly if frame rates over 30Hz are selected
Summary: External Monitor not waking up properly if frame rates over 30Hz are selected
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 6.2.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: multiscreen, regression
Depends on:
Blocks:
 
Reported: 2024-11-24 08:07 UTC by Evert Vorster
Modified: 2025-01-02 18:58 UTC (History)
5 users (show)

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


Attachments
Journal of the run described here. (1.05 MB, text/plain)
2024-11-24 08:07 UTC, Evert Vorster
Details
The output of ddcutil interrogate (251.63 KB, text/plain)
2024-12-10 05:36 UTC, Evert Vorster
Details
The output of drm_info (206.70 KB, text/plain)
2024-12-16 17:03 UTC, Evert Vorster
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Evert Vorster 2024-11-24 08:07:21 UTC
Created attachment 176079 [details]
Journal of the run described here.

SUMMARY
My system is set to switch off its monitors after a period of inactivity, but not suspend or hibernate. So, only monitors are switched off until I wiggle a mouse or hit a key. 

Up until about a week ago, this hardware worked perfectly, and after a boot, it also works perfectly, so I am sure this issue is not hardware related. 

When the monitors are turned on, the internal monitor on the laptop works normally. The external monitor looks like it is coming out of its powersave state, but after a second or so tells me that it has no signal and goes back to sleep. 
At the same time, KDE extends my desktop to this monitor. After a few seconds, KDE removes this monitor from the configuration, and displays all my windows on the internal monitor on the laptop. Before you can do anything, KDE then realizes there is an external monitor connected, tries to wake it up and extends the display area to it. 

This process repeats indefinitely, rendering the computer unusable. 
If I switch off the external monitor, KDE extends my desktop to it, and stays that way. 

If I physically unplug the monitor, KDE displays the appropriate desktop size, and I can use the computer again. However, if I plug the monitor back in, this little dance resumes. 

When powering off the computer completely, and connecting the monitor to it, and then powering up, it works normally, as it used to do up until a week or so ago. Then, if I wander away from the computer and leave it alone for long enough for the monitors to go to sleep, it enters this state again. 

STEPS TO REPRODUCE
1. Leave computer alone for long enough for the monitors to go to sleep.
2. Wake up the computer by wiggling mouse, or pressing a key on the keyboard.

OBSERVED RESULT
External Monitor is not properly woken up, and KDE is extending the desktop to a monitor that is not on/ready.

EXPECTED RESULT
External Monitor to be properly woken up, and given enough time to get ready. While it is getting ready, the desktop must not be extended to it.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.11.5-arch1-1.1-g14 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7945HX3D with Radeon Graphics
Memory: 62.0 GiB of RAM
Graphics Processor: AMD Radeon 610M
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Strix G733PYV_G733PYV
System Version: 1.0

ADDITIONAL INFORMATION
It is an Optimus laptop, with an nVidia 4090 mobile GPU. Latest nvidia-open dkms drivers are installed.


I will attach a journal of the run where I let the system run like this for a little while. It is a little wordy, but blocks of errors like this is what is most interesting to me:
---------------------snip-------------------
Nov 24 07:50:10 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 9748, resource id: 16777272, major code: 129 (SHAPE), minor >
Nov 24 07:50:25 Evert.Strix google-chrome-stable[2928]: [2923:2950:1124/075025.343187:ERROR:registration_request.cc(291)] Registration response error messa>
Nov 24 07:52:23 Evert.Strix kwin_wayland[1245]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Nov 24 07:53:41 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 12492, resource id: 16777302, major code: 129 (SHAPE), minor>
Nov 24 07:57:10 Evert.Strix google-chrome-stable[2928]: [2923:2950:1124/075710.921921:ERROR:registration_request.cc(291)] Registration response error messa>
Nov 24 08:06:53 Evert.Strix kwin_wayland[1245]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Nov 24 08:16:06 Evert.Strix kwin_wayland[1245]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Nov 24 08:21:02 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 14652, resource id: 16777362, major code: 129 (SHAPE), minor>
Nov 24 08:22:12 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 14789, resource id: 16777368, major code: 129 (SHAPE), minor>
Nov 24 08:23:07 Evert.Strix kwin_wayland[1245]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Nov 24 08:23:07 Evert.Strix google-chrome-stable[2928]: [3001:3001:1124/082307.807155:ERROR:shared_image_manager.cc(250)] SharedImageManager::ProduceSkia: >
Nov 24 08:23:48 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 15839, resource id: 16777392, major code: 129 (SHAPE), minor>
Nov 24 08:24:04 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 15933, resource id: 16777395, major code: 129 (SHAPE), minor>
Nov 24 08:24:52 Evert.Strix google-chrome-stable[2928]: [2923:2923:1124/082452.773965:ERROR:interface_endpoint_client.cc(725)] Message 0 rejected by interf>
Nov 24 08:25:42 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 16143, resource id: 16777406, major code: 129 (SHAPE), minor>
Nov 24 08:27:06 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 16468, resource id: 16777415, major code: 129 (SHAPE), minor>
Nov 24 08:28:44 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 16727, resource id: 16777430, major code: 129 (SHAPE), minor>
Nov 24 08:30:06 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 16969, resource id: 16777445, major code: 129 (SHAPE), minor>
Nov 24 08:31:14 Evert.Strix google-chrome-stable[2928]: [2923:2923:1124/083114.462826:ERROR:interface_endpoint_client.cc(725)] Message 0 rejected by interf>
Nov 24 08:33:16 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 17177, resource id: 16777451, major code: 129 (SHAPE), minor>
Nov 24 08:35:53 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 17425, resource id: 16777463, major code: 129 (SHAPE), minor>
Nov 24 08:36:45 Evert.Strix kwin_wayland[1245]: kwin_core: XCB error: 3 (BadWindow), sequence: 17561, resource id: 16777466, major code: 129 (SHAPE), minor>
Nov 24 08:45:50 Evert.Strix kwin_wayland[1245]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Nov 24 08:58:46 Evert.Strix kded6[1408]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_01_00.1.hdmi-stereo"
Nov 24 08:58:46 Evert.Strix plasmashell[1463]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_01_00.1.hdmi-stereo"
Nov 24 08:58:47 Evert.Strix org_kde_powerdevil[1524]: Sleep event. connector=card1-eDP-1, dref not set
Nov 24 08:58:49 Evert.Strix org_kde_powerdevil[1524]: Emitting DDCA_Display_Status_Event( 8363.108:  DDCA_EVENT_DPMS_ASLEEP, card1-eDP-1, dref: Display_Ref>
Nov 24 08:58:49 Evert.Strix org_kde_powerdevil[1524]: Executed 1 registered callbacks.
Nov 24 09:06:01 Evert.Strix kernel: nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed.
Nov 24 09:06:01 Evert.Strix systemd[1]: Started dbus-:1.2-org.kde.powerdevil.backlighthelper@3.service.
░░ Subject: A start job for unit dbus-:1.2-org.kde.powerdevil.backlighthelper@3.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit dbus-:1.2-org.kde.powerdevil.backlighthelper@3.service has finished successfully.
░░ 
░░ The job identifier is 3773.
------------------------------snip-------------------------
Comment 1 Evert Vorster 2024-11-24 08:10:59 UTC
A bit more context, if it may be helpful. 

I also have a USB-C laptop dock with HDMI ports. When the system is in this weird state, if I plug the external monitors into the USB-C dock, the display on the dock says that there is a monitor connected, but it does not appear that the computer is trying to use it.
Comment 2 Evert Vorster 2024-11-25 13:00:05 UTC
A bit more information. I downgraded this system to version to 6.2.2, and this issue is not happening anymore. 
To be clear, this Arch system was completely downgraded to whatever was current on 2024-11-03.
Comment 3 Nate Graham 2024-11-25 21:48:45 UTC
What models are the monitors in question?
Comment 4 Nate Graham 2024-11-25 21:49:17 UTC
6.2.3 changelog, FWIW: https://kde.org/announcements/changelogs/plasma/6/6.2.2-6.2.3/
Comment 5 Evert Vorster 2024-11-26 07:17:29 UTC
Hi there!

Thanks for looking at this. The monitor is a BenQ EX3210U. 

It is running at 4K at 120fps, color profile used is the built-in one, and I am not using its HDR capability. 
It is connected to the laptop's built-in HDMI port with an HDMI 2.1 cable. I tried several cables, and also tried connecting it to a USB-C hub, which is also capable of driving this monitor at 4K 120fps. 

What I have noticed is that this monitor is a little slow to wake up, so maybe sometime in the recent history a time-out waiting for the screen to become ready was changed?
Comment 6 Evert Vorster 2024-11-26 07:19:28 UTC
Oh, a small correction, this also happens on plasma 6.2.2, my previous statement was incorrect... I just did not give it enough time to get confused. 

Worthy of note is that when you first boot up, it all works properly. It is only when the monitors have been powered down due to inactivity that this issue pops up.
Comment 7 Evert Vorster 2024-11-26 07:22:02 UTC
One more small clarification. 
The monitors in question are the laptop's built-in monitor and the BenQ external monitor. The BenQ is to the right of the laptop, and when plugged in is set to be the Primary display in KDE. 

When this issue pops up, I can power down the monitor, and then set it to be disabled, power it back on and then re-enable it, and that seems to cure it until the next time the monitors are set to their standby state.
Comment 8 Evert Vorster 2024-12-03 07:12:40 UTC
Hi there!

Doing some more testing on this issue. 
This issue is not apparent when running this monitor as an external monitor on Windows 11. 
Monitor is configured as 4K@120Hz. Windows enters power save mode and monitors turns off normally. Then, on a wake up event the monitor wakes up normally, and resumes 4K@120Hz. 

In Linux, when the monitor is configured as 4K@120Hz, when the computer goes into powersave mode and turns the monitors off, this monitor turns off as well. On wakeup, this monitor wakes up, but the desktop does not extend to it. Then, the monitor turns enters power save again, which triggers the desktop to extend to it, which wakes up the monitor, but it claims that it is not receiving a signal. After a while it switches over to standby mode again. 

At 4K@30Hz, the monitor wakes up normally from standby mode. 

At 4K@60Hz, the monitor exhibits the same issues as with 120Hz.

From this I can conclude that it is not my hardware. 
Also, it works normally with a refresh rate of 30Hz. 

The BenQ monitor does take a little longer to wake up from power saving that what I am used to with other monitors, especially when running higher refresh rates. 
Is there some hardcoded timeout that KDE has to check to see if the monitor has woken up properly from standby? If so, can this be increased for higher refresh rates than 30?
Comment 9 Evert Vorster 2024-12-03 07:57:33 UTC
OK, maybe a video showing the issue is a little more helpful. 

Please, watch the video at this link to see the issue in action:
https://youtu.be/uM6j6lUzARk
It is only two or three minutes long, showing how the monitor works at 120Hz, but does not wake up properly at 120Hz. 
When switched to 30Hz, it wakes up, and then when set to 120Hz again it accepts it again and works normally.
Comment 10 Jakob Petsovits 2024-12-09 00:35:08 UTC
On Wayland, KWin (via kernel) is responsible for anything involving monitor wake-ups. Reassigning projects, in the hope that some knowledgeable people scour the KWin bug list even if they miss out on PowerDevil bugs.
Comment 11 Zamundaaa 2024-12-09 13:00:15 UTC
I see two ways this could happen:
1. the driver messes up and bandwidth negotiation isn't done correctly. The display gets a signal it can't work with, and thus turns off again
2. we send a DDC request to the display, and the display messes up somehow

To test the former, please put
> KWIN_DRM_PREFER_COLOR_DEPTH=24
into /etc/environment and reboot. For the latter, try the same with
> POWERDEVIL_NO_DDCUTIL=1
Comment 12 Evert Vorster 2024-12-10 05:06:44 UTC
I am testing this now. I do notice another inconsistency, though. 

On the Amazon this specific monitor is listed as 144Hz, but in both Windows and Linux the refresh rate tops out at 120Hz.

https://www.amazon.com/dp/B09NF2472W?ref=ppx_yo2ov_dt_b_fed_asin_title&th=1

I'll post the results of the testing as soon as I am done.
Comment 13 Evert Vorster 2024-12-10 05:21:59 UTC
Thanks for looking into this. Unfortunately, it looks like it will need more investigation. 

I tested with
> KWIN_DRM_PREFER_COLOR_DEPTH=24
in /etc/environment and rebooted. 

No change in behavior when the monitor is at 120Hz. ie: It does to sleep, and on wakeup I have exactly the same simptoms as before. 

With
> POWERDEVIL_NO_DDCUTIL=1
The sypmtoms are exactly the same too. 

So, let's dig. 
[code]
[evert@Evert ~]$ ddcutil detect
Invalid display
   I2C bus:  /dev/i2c-7
   DRM connector:           card1-eDP-1
   EDID synopsis:
      Mfg id:               BOE - BOE
      Model:                NE173QHM-NZ2
      Product code:         2921  (0x0b69)
      Serial number:        
      Binary serial number: 0 (0x00000000)
      Manufacture year:     2022,  Week: 24
   This is a laptop display.  Laptop displays do not support DDC/CI

Invalid display
   I2C bus:  /dev/i2c-17
   DRM connector:           card0-HDMI-A-1
   EDID synopsis:
      Mfg id:               BNQ - UNK
      Model:                BenQ EX3210U
      Product code:         32678  (0x7fa6)
      Serial number:        ETW5N05026SL0
      Binary serial number: 16843009 (0x01010101)
      Manufacture year:     2022,  Week: 21
   DDC communication failed. (getvcp of feature x10 returned Error_Info[EIO in ddc_write_read_with_retry, causes: EIO])
[/code]

This is with > POWERDEVIL_NO_DDCUTIL=1 still active. I'll remove it, and re-test with this command.
Comment 14 Evert Vorster 2024-12-10 05:36:21 UTC
Created attachment 176481 [details]
The output of ddcutil interrogate

The output of ddcutil interrogate
Comment 15 Evert Vorster 2024-12-10 05:38:25 UTC
Looking at the output of ddcutil detect, it seems that there is some issue with ddcutil reading this monitor, and might very well be the cause of this issue. 

I have added the output of ddcutil interrogate to this bug report, and will go pester the people at ddcutil github for now, and see if we can get this issue cleared up.
Comment 16 Evert Vorster 2024-12-10 07:14:44 UTC
OK, it has been a little adventure, but unfortunately I am back here with nothing good to report. 
I adopted the ddcutil-dev-git package in Arch Linux, then updated the dev branch to the latest branch (2.2.0-dev), and then installed that into my system. 

The output of ddcutil detect has changed:
<code>
[evert@Evert ~]$ ddcutil detect
Invalid display
   I2C bus:  /dev/i2c-3
   DRM connector:           card1-eDP-1
   EDID synopsis:
      Mfg id:               BOE - BOE
      Model:                NE173QHM-NZ2
      Product code:         2921  (0x0b69)
      Serial number:        
      Binary serial number: 0 (0x00000000)
      Manufacture year:     2022,  Week: 24
   This monitor does not support DDC/CI. (I2C slave address x37 is unresponsive.)

Invalid display
   I2C bus:  /dev/i2c-17
   DRM connector:           card0-HDMI-A-1
   EDID synopsis:
      Mfg id:               BNQ - UNK
      Model:                BenQ EX3210U
      Product code:         32678  (0x7fa6)
      Serial number:        ETW5N05026SL0
      Binary serial number: 16843009 (0x01010101)
      Manufacture year:     2022,  Week: 21
   This monitor does not support DDC/CI. (I2C slave address x37 is unresponsive.)
</code>

So, ddcutil now sees the monitor, but claims that it is not supported. 
I had a root around the monitor settings, and there is no DDC/CI setting to mess with. The closest was HDMI-CEC, which was off. I turned it on, but still no joy. 

One thing I am noticing that is kind of weird to me, is that if I turn off or unplug the external monitor, KDE does not detect this, and happily outputs to a dead display. Once I unplug the HDMI cable, though, then it realizes the monitor is gone and switches to the internal laptop panel only. 

In my understanding, there are quite a few monitors that do not support DDC/CI, and so it follows that this should not be relied upon exclusively to detect and configure displays. 

The monitor is fairly expensive and modern, being only made in 2022. Also, this issue does not seem to be present in Windows, so there is a little room for improvement here, I guess. 

I tested with HDR on and off, and every single time it comes down to display update rate. 

When the display update rate is 30fps, it wakes up properly from sleep mode, and when a higher update rate is used it does not. 
When setting the display to 120fps and rebooting the computer, the first time I log in there is a fairly good chance that the display works properly. If I take a little long to type the login password, the monitor goes to sleep and then it does not wake up properly. 

On a related mode, the monitor does have an auto-power off mode, which has been disabled. So, powersave and powered down are different modes. With that HDMI-CEC on, it wakes up from powered down mode too, but still the same issue persists, leading me to think that this is not due to the monitor.
Comment 17 Evert Vorster 2024-12-13 04:16:23 UTC
To tie things together a bit on this bug report. 

On the ddcutil front I have discovered that if the monitor is powered down and the HDMI cable unplugged when the laptop is booted, and the monitor then powered on and connected, it claims to support DDC/CI. 
If, however, the monitor is in standby mode and connected when powering up the laptop, it claims not to support DDC/CI. 
Bug report with ddcutil here: https://github.com/rockowitz/ddcutil/issues/476

However, no matter if DDC/CI is supported, the monitor does not wake up properly from sleep. 
This is making me think that the DDC/CI support is a separate driver issue: Filed a topic in the nVidia forum on this:
https://forums.developer.nvidia.com/t/external-monitor-inconsistent-ddc-ci-detection/316597

However, the original issue still remains on this laptop, which is that the monitor does not wake up properly when frame rates over 30Hz is selected. Hoping that this might be a driver issue as well, I filed a separate topic on this on the nVidia forums:
https://forums.developer.nvidia.com/t/external-monitor-fails-to-wake-up-from-powersave-mode-if-refresh-rate-is-higher-than-30hz/316612
Comment 18 Zamundaaa 2024-12-16 16:07:07 UTC
(In reply to Evert Vorster from comment #16)
> One thing I am noticing that is kind of weird to me, is that if I turn off
> or unplug the external monitor, KDE does not detect this, and happily
> outputs to a dead display. Once I unplug the HDMI cable, though, then it
> realizes the monitor is gone and switches to the internal laptop panel only. 
Yes, that's just how HDMI works. It's shit.

> In my understanding, there are quite a few monitors that do not support
> DDC/CI, and so it follows that this should not be relied upon exclusively to
> detect and configure displays. 
It's not used for anything except brightness control.

When the display doesn't wake up, please run drm_info and attach the output here.
Comment 19 Evert Vorster 2024-12-16 17:03:49 UTC
Created attachment 176681 [details]
The output of drm_info

Thanks again for looking into this. 

As a point of clarification, it is not that the monitor does not wake up, it does. It seems that it is not getting a proper signal from the laptop and goes back to sleep. 

I see that there has been one view of the video, if that was you, I hope it made what I am trying to explain a bit more clear. 

In any case, the output of drm_info is attached. 
I am a little confused as to the exact moment that you would like the output of drm_info to be captured? Is it when the computer is outputting to the monitor and it is not detecting a signal, or when the computer is not outputting to the monitor and the entire desktop is on one screen only? 
It switches between these two states. 
In this case I captured the output when it was displaying everything on the laptop's built-in screen.
Comment 20 Zamundaaa 2024-12-16 20:22:54 UTC
> I am a little confused as to the exact moment that you would like the output of drm_info to be captured? Is it when the computer is outputting to the monitor and it is not detecting a signal, or when the computer is not outputting to the monitor and the entire desktop is on one screen only? 
I need it from when the signal isn't getting detected, to confirm whether or not it's KWin that's doing something wrong, or if the problem is on the driver side.
Comment 21 Evert Vorster 2024-12-22 13:28:46 UTC
Hi there!

Thanks for looking into this. 
With a bit of help from the folks at nVidia, we tracked down the issue to the version of nvidia drivers that I am running. 
I was running the latest version of the drivers available on my platform, 565.77. When trying an older version of the driver, 550.147 this issue is not apparent, so it would appear that this is not a bug with kwin.