Application: plasmashell (5.21.4) Qt Version: 5.15.2 Frameworks Version: 5.80.0 Operating System: Linux 5.10.22-100.fc32.x86_64 x86_64 Windowing System: Wayland Drkonqi Version: 5.21.4 Distribution: Fedora 34 (KDE Plasma) -- Information about the crash: - What I was doing when the application crashed: I have a Lenovo USB-C dock which uses DisplayLink to drive two monitors. For reasons unrelated to this bug report I currently have one monitor connected to the dock and one connected directly to the laptop over HDMI. I was trying to enable the monitor that I have connected directly to the laptop using HDMI. When I first start Plasma, the dock monitor is automatically enabled (due to my display configuration). When I try to enable the HDMI monitor, Plasma freezes and then stops properly rendering the dock monitor (I can move the mouse cursor but nothing else. If I find a window title bar I can move the window around but I can't see the results of my movement). The HDMI monitor does not come on. My laptop monitor is still functioning normally. If I move the display settings tool to my laptop monitor and try again to configure my displays, Plasma crashes (with the backtrace shown here). I aslo see a lot of other application crashes (Konversation, Dolphin, Konsole, or anything else I had loaded). I assume these are related to Plasma crashing so I am not reporting them. My laptop monitor still works but the other two are black. If I try to configure the monitors a third time, everything freezes, the caps lock light doesn't come on any more when I click the key, and my laptop's fans spin up. I have to hold the power button to shut down. I have tried this whole operation a couple of times and it is reproduceable. The crash can be reproduced every time. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault [KCrash Handler] #4 0x00007fb332c8fa2a in QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) () at /lib64/libQt5Core.so.5 #5 0x00007fb33320b14c in void QWindowSystemInterface::handleWindowScreenChanged<QWindowSystemInterface::DefaultDelivery>(QWindow*, QScreen*) () at /lib64/libQt5Gui.so.5 #6 0x00007fb330b337c0 in QtWaylandClient::QWaylandWindow::handleScreensChanged() () at /lib64/libQt5WaylandClient.so.5 #7 0x00007fb332e194b0 in void doActivate<false>(QObject*, int, void**) () at /lib64/libQt5Core.so.5 #8 0x00007fb33122cc04 in ffi_call_unix64 () at /lib64/libffi.so.6 #9 0x00007fb33122c107 in ffi_call () at /lib64/libffi.so.6 #10 0x00007fb3326b5d10 in wl_closure_invoke.constprop () at /lib64/libwayland-client.so.0 #11 0x00007fb3326b642b in dispatch_event.isra () at /lib64/libwayland-client.so.0 #12 0x00007fb3326b661c in wl_display_dispatch_queue_pending () at /lib64/libwayland-client.so.0 #13 0x00007fb330b276d3 in QtWaylandClient::QWaylandDisplay::flushRequests() () at /lib64/libQt5WaylandClient.so.5 #14 0x00007fb332e194fd in void doActivate<false>(QObject*, int, void**) () at /lib64/libQt5Core.so.5 #15 0x00007fb332e1bb3a in QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal) () at /lib64/libQt5Core.so.5 #16 0x00007fb332e1c2d4 in QSocketNotifier::event(QEvent*) () at /lib64/libQt5Core.so.5 #17 0x00007fb333a57e73 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 #18 0x00007fb332de8f48 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5 #19 0x00007fb332e3617f in socketNotifierSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5Core.so.5 #20 0x00007fb3312bd4cf in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #21 0x00007fb3313114e8 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #22 0x00007fb3312bac03 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #23 0x00007fb332e356f8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #24 0x00007fb332de79b2 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5 #25 0x00007fb332def544 in QCoreApplication::exec() () at /lib64/libQt5Core.so.5 #26 0x0000556a55cc7fd1 in main () [Inferior 1 (process 4847) detached] Possible duplicates by query: bug 435976, bug 435618, bug 435427, bug 435261, bug 435192. Reported using DrKonqi
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
Fixed by: https://codereview.qt-project.org/c/qt/qtwayland/+/381271
Looks like it may be happening again; see Bug 473020.