Bug 435265

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!