| Summary: | Plasma Wayland crashes in QtWaylandClient::QWaylandWindow::handleScreensChanged() when using combined (direct) HDMI and DisplayLink outputs | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Simon Redman <simon> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | kde, mikaela.szekely, nate, plasma-bugs, xaver.hugl |
| Priority: | NOR | Keywords: | drkonqi, wayland |
| Version: | 5.21.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
The results of drminfo on the working X11 session
The results of drminfo on the "frozen" wayland session Output of startplasma-wayland run as described in comment 8 The results of drminfo as described in comment 8 on the working X11 session The results of drminfo as described in comment 8 on the working X11 session Output of startplasma-wayland run as described in comment 8 The results of drminfo as described in comment 8 on the "frozen" wayland session |
||
|
Description
Simon Redman
2021-04-21 06:53:36 UTC
Switching the component to "Multi-screen support" since that seems more appropriate than general. I do not understand Plasma components very well. Does it work properly on X11, or is it broken there too? (In reply to Nate Graham from comment #2) > Does it work properly on X11, or is it broken there too? No, the issues do not reproduce in X11. Moreover, once I configure the displays in X11, I am able to log out and log back into the Wayland session and the displays stay configured. In 5.21 plasmashell and some other apps generally crash on Wayland when you disable an output, it should be unrelated to the display problems (and is fixed in 5.22). The hang is almost certainly KWin triggering a kernel bug. > once I configure the displays in X11, I am able to log out and log back into the Wayland session and the displays stay configured. Then the displays failing to configure properly is most likely a duplicate of https://bugs.kde.org/show_bug.cgi?id=433107. To confirm some more information would be good: What GPU(s) are in the laptop? What's in ~/.local/share/sddm/wayland-session.log? Ideally test with the environment variable QT_LOGGING_RULES="kwin_*.debug=true;kwin_libinput.debug=false" set for the session and upload the file afterwards from a X11 session (the file gets overwritten if you log into wayland). The output of drminfo both in the working X session and when it doesn't work on Wayland could also be useful (not necessarily necessary though). Created attachment 137856 [details]
The results of drminfo on the working X11 session
Created attachment 137857 [details]
The results of drminfo on the "frozen" wayland session
> What GPU(s) are in the laptop? There are two hardware GPUs and the "software GPU" which drives the DisplayLink displays: Intel HD Graphics 630 (driving the laptop screen and the HDMI screen) Nvidia GeForce GTX 1050 Mobile (not connected to any display) Display Link / EVDI / "Software GPU" (The Info Center OpenGL page doesn't have the Vendor or Device field populated for this one) For some reason I can't get ~/.local/share/sddm/wayland-session.log to appear. Is there something special I need to do? I did log in with sddm. I have attached the results of running drminfo for both X11 and wayland. In the wayland case, I ran the command after configuring my displays at which time neither of the external monitors was drawing any updates except the mouse cursor. Based on the description in https://bugs.kde.org/show_bug.cgi?id=433107 I agree that it sounds likely related. One of my weekend goals is to build kwin so I'll try out those patches you mentioned and see if it behaves any better. Sorry, I should've specified the drminfo command more closely, it only outputs for GPU 0 by default. Something like this would be most useful (DisplayLink AFAIK creates a bunch of virtual GPUs): > drminfo -a -r -c 0 && drminfo -a -r -c 1 && drminfo -a -r -c 2 && drminfo -a -r -c 3 && drminfo -a -r -c 4 && drminfo -a -r -c 5 From what you already attached I would expect the outputs connected to the Intel GPU to work though, except for X apparently using software cursors the exact same display routing is used. > Moreover, once I configure the displays in X11, I am able to log out and log back into the Wayland session and the displays stay configured. The output of drminfo when that happens could be useful as well. > For some reason I can't get ~/.local/share/sddm/wayland-session.log to appear. Is there something special I need to do? I did log in with sddm. Normally not. Instead of logging in through sddm though you could also start plasma from a tty to obtain the log: > QT_LOGGING_RULES="kwin_*.debug=true;kwin_libinput.debug=false" dbus-run-session startplasma-wayland &> wayland-session.log Created attachment 137916 [details] Output of startplasma-wayland run as described in comment 8 Attached output of startplasma-wayland run as described in comment 8 Created attachment 137917 [details] The results of drminfo as described in comment 8 on the working X11 session Created attachment 137918 [details] The results of drminfo as described in comment 8 on the working X11 session Replacing this attachment. I did not have the monitors plugged into the correct outputs when running previously. Created attachment 137919 [details] Output of startplasma-wayland run as described in comment 8 Re-attaching this attachment for the same reason as above. Created attachment 137920 [details] The results of drminfo as described in comment 8 on the "frozen" wayland session > One of my weekend goals is to build kwin so I'll try out those patches you mentioned and see if it behaves any better. I built kwin from master (commit e9fcd9584ef18f910ac18357d660663fd3baf5ce) and I can easily enable and disabled monitors :) -- You're almost certainly correct about the connection to https://bugs.kde.org/show_bug.cgi?id=433107 -- Is there any information you'd like me to collect on this new version? I spoke too soon :( I am now able to enable and disable my second Displaylink display which isn't the configuration described in this bug but also used to not work. However, with the configuration described in this bug (one external HDMI + one Displaylink), the behavior of the external monitors "freezing" stays. (Apps don't crash any more, but you've already mentioned that was known-fixed in 5.22) What you can do to debug this further is to enable drm debugging with > echo 0xFE | sudo tee /sys/module/drm/parameters/debug and capture the information with > sudo dmesg -w > dmesg.log which will write a huge amount of information about drm calls we're doing and what the kernel does in reaction into dmesg.log until you stop it with ctrl+c. As it really is a lot (100KB/s and more) you should ideally only start that command, enable the HDMI monitor and cancel it immediately afterwards. Something I don't think you've mentioned yet: Does the HDMI monitor also not work when you don't have anything connected to the DisplayLink connectors? If so then it would be ideal to get the dmesg info with that configuration. If not then it would be interesting if drminfo shows anything different Looks like it may be happening again; see Bug 473020. |