| Summary: | Enabling HDR freezes system | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | jroddev <kde.backboned759> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | nate, xaver.hugl |
| Priority: | NOR | ||
| Version: | 6.0.3 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
kwin-drm-debug.log
dmesg-drm-debug.log kwin-drm-debug 90 seconds wait dmesg-drm-debug 90 second wait |
||
|
Description
jroddev
2024-04-11 23:26:59 UTC
hardware probe: https://linux-hardware.org/?probe=66b49c3998 We're gonna need some debug information, ideally from both KWin and the driver side. The best way to get it is probably to enable HDR, disconnect the monitor, log out, switch to a tty, connect the monitor again and then run the script from https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues Afterwards, just attach kwin-drm-debug.log and dmesg-drm-debug.log here Created attachment 168730 [details]
kwin-drm-debug.log
Created attachment 168731 [details]
dmesg-drm-debug.log
hmm, I see nothing obviously wrong in there. There's a few atomic tests that fail with "needs modeset", but that's a normal part of KWin's startup sequence, and at the very end of the log I see KWin successfully doing a modeset to turn the screens on. Maybe the problem only happens later... Could you bump the "sleep 3" in the script to "sleep 20" or something like that, and attach the logs for that again? I changed it to 90 seconds for good measure. It might also be worth noting that I can't recover the system once the monitor is plugged in. It locks up immediate (at least visually) and even after disconnecting the monitor it doesn't start working again. Even trying to switch out to terminals once the monitor is disconnected doesn't work. Need to reboot to get back in. Created attachment 168990 [details]
kwin-drm-debug 90 seconds wait
Created attachment 168991 [details]
dmesg-drm-debug 90 second wait
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Whoops. Didn't know I needed to set Status to Reported hmm, the drm log is cut off in the exact same spot as the last one. That suggests to me something is going very wrong in the kernel. Please report this to NVidia, they might be able to do more about this The lockout no longer occurs. I'm not sure exactly what fixed it, but it could be - Performed a bios updated on the motherboard. - Switched from 5 year old Manjaro to fresh AuroraOS. - Other general updates since I reported the issue. Now when I enable HDR the system freezes for a moment and then resumed. The HDR setting gets set back to disabled (after closing and reopening system settings). I believe this is now expected behaviour since there seems to be a problem with either my monitor or graphic card/drivers. Yes, that's more in line with expectations at least - the driver rejects enabling HDR for some reason, and KWin won't save the setting when that happens |