Created attachment 137273 [details] The working X11 session with both monitors visible. SUMMARY When running plasma under a wayland session kscreen only displays 1 of a pair of identical external monitors. Monitors are AOC 31.5" 2k monitors connected via display port to a Lenovo Gen2 Thunderbolt dock. Plasma session under X11 displays both (see attachment for working x11). Plasma session under wayland only displays one of the pair. STEPS TO REPRODUCE 1. Start plasma with a wayland session 2. Open KScreen OBSERVED RESULT Only a single Q32v3 monitor is present in the list of devices EXPECTED RESULT Both of the Q32v3 monitors are present in the list of Devices SOFTWARE/OS VERSIONS KDE Neon Linux/KDE Plasma: Operating System: KDE neon 5.21 KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.11.0-051100-generic OS Type: 64-bit Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8265U CPU @ 1.60GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 ADDITIONAL INFORMATION
Not exactly the same as Bug 432707, but looks like it's the same root cause of discarding the last-detected DisplayPort monitor. So when one is connected, none are detected, and when two are connected, only one is detected. *** This bug has been marked as a duplicate of bug 432707 ***
Does the second monitor get detected at all, or does it just not turn on? If it's the former then it's a different bug. In either case, please provide ~/.local/share/sddm/wayland-session.log
I don't believe it gets detected but I'll post the log file when I'm at the dock tomorrow and confirm
Created attachment 137391 [details] ~/.local/share/sddm/wayland-session.log Please see attached ~/.local/share/sddm/wayland-session.log
I don't see any relevant errors, I assume it's a different bug. Could you attach the file again, but now with the environment variable QT_LOGGING_RULES="kwin_*.debug=true;kwin_libinput.debug=false" set for the session (put it in /etc/environment & reboot)? That should give us more information.
Will do. Thank you for taking the time to investigate this.
Created attachment 137433 [details] Latest /.local/share/sddm/wayland-session.log Have enabled QT_LOGGING_RULES env var as requested. ~ ❯ echo $QT_LOGGING_RULES kwin_*.debug=true;kwin_libinput.debug=false
Okay, that looks all fine. I have a few questions about your setup: * Is it always the same monitor that doesn't work? * If you unplug the working monitor, I assume the other one stays blank? * Are you waiting with booting the laptop while it's connected to the docking station, or do you hotplug it? If the latter, what happens if you reboot after plugging it in? * what does "ls /dev/dri/" output if you have the docking station connected, and not connected?
(In reply to Zamundaaa from comment #8) > Okay, that looks all fine. I have a few questions about your setup: > > * Is it always the same monitor that doesn't work? Yes. That is the currently re-producable behavior. > * If you unplug the working monitor, I assume the other one stays blank? Correct > * Are you waiting with booting the laptop while it's connected to the > docking station, or do you hotplug it? If the latter, what happens if you > reboot after plugging it in? If I cold boot after previously having used a working X11 session then I am presented with 3 (correctly) working monitors when being greeted by SDDM. If I select a plasma x11 session then all is fine. If however I choose a wayland session then I have only 2 / 3 monitors available for selection. If I plug in the TB dock when the laptop is in a suspended state with a sing currently active wayland session (i.e from previously logging in -performing work and then closing the lid), on resuming I will only have 2/3 monitors to choose from. > * what does "ls /dev/dri/" output if you have the docking station connected, > and not connected? Will get this info shortly. Under X11 it's ~ ❯ ls /dev/dri/ by-path card0 renderD128
Wayland not connected: # ls -la /dev/dri total 0 drwxr-xr-x 3 root root 100 Apr 10 13:40 . drwxr-xr-x 23 root root 5000 Apr 10 13:41 .. drwxr-xr-x 2 root root 80 Apr 10 13:40 by-path crw-rw----+ 1 root video 226, 0 Apr 10 13:40 card0 crw-rw----+ 1 root render 226, 128 Apr 10 13:40 renderD128
Wayland Connected: drwxr-xr-x 3 root root 100 Apr 10 13:40 . drwxr-xr-x 23 root root 5240 Apr 10 13:45 .. drwxr-xr-x 2 root root 80 Apr 10 13:40 by-path crw-rw----+ 1 root video 226, 0 Apr 10 13:45 card0 crw-rw----+ 1 root render 226, 128 Apr 10 13:40 renderD128 root@seattle:/home/andmas#
One more thing: What's the output of drminfo -a -r ? That should give us more information about what KWin seems to ignore. The output of that on X11 with the display enabled could be useful as well.
Any ideas what package would I likely need to install for drminfo ?
Hmm, the package is called drm-info for Ubuntu but it's probably not in Neon yet (got added with Ubuntu 20.10). You can compile it yourself very easily from https://github.com/kraxel/drminfo though: git clone https://github.com/kraxel/drminfo.git && cd drminfo && mkdir build && cd build && meson && ninja
Created attachment 137702 [details] output with x11 -- working correctly
Created attachment 137703 [details] Wayland not docked - single screen
Created attachment 137704 [details] Wayland session docked This contains the output of the DRM info command when the Wayland session was docked. At this stage though, it's worth noting that plasmashell has crashed (segfault). Additionally, the third unique, but previously working monitor (1920x1080) is no longer turning on and any attempt to do so hard locks the machine.
Created attachment 137705 [details] Plasma shell segfault debug trace log -- may be useful
The output is quite weird, it shows 4 connected displays... Aside from that I think that https://invent.kde.org/plasma/kwin/-/merge_requests/844 will solve the problem though, as it looks like KWin's just assigning display resources wrong and that MR makes that assignment smarter. Can you test if that does make it work?
I am happy to test but I haven't ever built a KDE component before so I don't really have a build chain set up. Even to compile the drm info I had to install a bunch of dependencies lib*-dev packages. Is there a nightly build package these nightly published somewhere that I could try ? Failing that how self contained is Kwin, is it likely that I need the build output of $x other modules in order to build kwin or is it a similar process to drminfo ?
There isn't any nightly package for this because it's not merged yet. The easiest way to build everything without modifying your system too much is kdesrc-build (https://community.kde.org/Get_Involved/development#Set_up_kdesrc-build), it builds all the KDE dependencies automatically and you can log in to a test session with all the built stuff that doesn't modify your system. I'm pretty confident that the patch will fix it though (it's already tested to fix something similar on another system) so you could also just wait for 3-4 weeks, then you should be able to simply test a 5.22 beta image in a live install.
Thank you for the investigation and getting back to me. I'm happy to wait 3 - 4 weeks and test it then. I am currently successfully using X11 but the Wayland sessions were getting close enough to daily driver ready that I figured I had some responsibility to start submitting bug reports. If you leave the ticket open I'll re-test when the beta drops.
I'm still experiencing this with Neon user edition. I'm changing to use the testing repos in the hopes that I can test the changes.
Sadly the patches couldn't go into 5.22 after all, so that probably won't fix anything. I can notify you when they get merged into master though, then you can test it with a Neon Unstable live boot.
That would be welcomed, thank you.
It appears the aforementioned merge request is still open but it appears to be somewhat stale. Is this an indication the fix won't be merged ? Or just that it's a busy time.
It requires a pretty large patchset that needs to go in first (https://invent.kde.org/plasma/kwin/-/merge_requests/877). If you want to test sooner I can update the merge request so that you can compile and test it in a live boot of KDE Neon developer edition.
That's ok. I just want to make sure I don't miss it :)
Am I correct that this is now merged into master ? Would the Neon developer channel likely have the change ?
No, that's just the requirement for the patch. The actual patch should be in very soon as well though - I added this bug to CC so it'll post a message here when it is merged.
Thank you.
Have updated the version to reflect that I am still experiencing this with the latest version.
Git commit b38bb416982babdae9941d41fa5b34717e5cae97 by Xaver Hugl. Committed on 08/09/2021 at 00:44. Pushed by zamundaaa into branch 'master'. Test DrmPipelines for outputs Not all combinations of connectors, crtcs and planes will work on all hardware, so we need to test the pipelines before using them. Related: bug 433107 M +170 -162 src/plugins/platforms/drm/drm_gpu.cpp M +5 -7 src/plugins/platforms/drm/drm_gpu.h M +0 -1 src/plugins/platforms/drm/drm_object_connector.h M +13 -0 src/plugins/platforms/drm/drm_output.cpp M +4 -0 src/plugins/platforms/drm/drm_output.h M +81 -78 src/plugins/platforms/drm/drm_pipeline.cpp M +15 -4 src/plugins/platforms/drm/drm_pipeline.h https://invent.kde.org/plasma/kwin/commit/b38bb416982babdae9941d41fa5b34717e5cae97
Thanks Zamundaaa. As soon as this makes it's way into Neon I'll give it a crack.
I can confirm that this is resolved on KDE Plasma Version 5.22.90 with Wayland on Neon. Thank you team.
Yay!