| Summary: | External Monitor not waking up properly if frame rates over 30Hz are selected | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Evert Vorster <evorster> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | adem4ik, jpetso, natalie_clarius, nate, xaver.hugl |
| Priority: | NOR | Keywords: | multiscreen, regression |
| Version First Reported In: | 6.2.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Journal of the run described here.
The output of ddcutil interrogate The output of drm_info |
||
|
Description
Evert Vorster
2024-11-24 08:07:21 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. 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. What models are the monitors in question? 6.2.3 changelog, FWIW: https://kde.org/announcements/changelogs/plasma/6/6.2.2-6.2.3/ 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? 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. 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. 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? 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. 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. 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 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. 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. Created attachment 176481 [details]
The output of ddcutil interrogate
The output of ddcutil interrogate
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. 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.
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 (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. 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.
> 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.
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. |