Bug 425586 - [Wayland] KDE does not detect a second monitor
Summary: [Wayland] KDE does not detect a second monitor
Status: RESOLVED DUPLICATE of bug 432707
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git master
Platform: Manjaro Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2020-08-20 12:14 UTC by Fervi
Modified: 2021-03-28 21:24 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot (218.94 KB, image/png)
2020-08-20 12:14 UTC, Fervi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fervi 2020-08-20 12:14:44 UTC
Created attachment 131037 [details]
Screenshot

Unfortunately, I don't know what logs are needed. KDE (Wayland) does not detect the second screen that is connected.

Maybe it's because the screen is connected to the second graphics card (dedicated).

Not only KDE has a problem with this, but also Enlightenment. Sway (wdisplays) and Gnome support.

On Xorg works (But I have Xorg issues, so I prefer using Wayland)
Comment 1 Méven Car 2020-08-20 15:01:06 UTC
Could you detail how screens are connected ?

What are your GPU, and their setup ?
Which screen are to connected to which ?

Knowing you, I assume you are running a recent plasma session.

Can you paste the result of :
`kscreen-doctor -o`
Comment 2 Fervi 2020-08-20 21:25:14 UTC
Well, I'm not entirely sure. It's a laptop.

Probably eDP-1 (laptop screen) uses an integrated graphics card (Vega 10).

HDMI-A-1 uses 100% dedicated (RX 5500M). The undetected image is from HDMI, probably because it is the second card.

Output: 1 B156HAN13.0 eDP-1-nieznany enabled connected primary Panel Modes: 0:1920x1080@120*! 1:1920x1080@48 2:1680x1050@120 3:1280x1024@120 4:1440x900@120 5:1280x800@120 6:1280x720@120 7:1024x768@120 8:800x600@120 9:640x480@120 Geometry: 0,0 1920x1080 Scale: 1 Rotation: 1 primary
Comment 3 Méven Car 2020-08-21 07:22:31 UTC
It seems it is a low level issue, at Wayland level it seems or wayland driver.
Comment 4 Fervi 2020-08-21 11:20:19 UTC
It is possible, although it is worth seeing how it is solved in widisplays or Gnome, because in them it works correctly. That's why I reported it in KDE / Enlightenment instead of "globally".
Comment 5 Bug Janitor Service 2020-09-06 12:39:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/243
Comment 6 Zamundaaa 2020-09-06 12:40:01 UTC
I am currently working on enabling multi GPU output support... Thanks for that hint about it working on GNOME, I found some commits that might be useful.
Comment 7 Alexandre Pereira 2020-09-08 22:00:18 UTC
(In reply to Zamundaaa from comment #6)
> I am currently working on enabling multi GPU output support... Thanks for
> that hint about it working on GNOME, I found some commits that might be
> useful.

I also currently use multi gpu. It works on swaywm also.
Using amd card + intel
Comment 8 Alexandre Pereira 2020-09-08 22:34:13 UTC
@Zamundaaa
btw I tested your patches on kwin.

It identified the monitor in the secondary gpu, but didn't display anything.
But at least it allowed me to turn it off on the systemsettings monitor page :)

It also seemed to respect the positioning of the monitor, and move windows there.

Thanks for the awesome work :)
Comment 9 Fervi 2020-09-09 13:12:56 UTC
It is good that the system is being prescribed. If you know how to compile the GIT KDE version on Manjaro, I will test it and let you know if it works properly.
Comment 10 Zamundaaa 2020-09-09 13:39:31 UTC
It is very much a WIP. Right now if you try with monitors connected to the secondary GPU, it'll crash. Still, thanks for testing!
I'll inform you when it's ready :)

@Fervi check out kdesrc-build: https://community.kde.org/Get_Involved/development#Set_up_kdesrc-build
Comment 11 Alexandre Pereira 2020-09-09 15:24:39 UTC
(In reply to Zamundaaa from comment #10)
> It is very much a WIP. Right now if you try with monitors connected to the
> secondary GPU, it'll crash. Still, thanks for testing!
> I'll inform you when it's ready :)
> 
> @Fervi check out kdesrc-build:
> https://community.kde.org/Get_Involved/development#Set_up_kdesrc-build

Actually, I tried it with a monitor connected to the secondary GPU and it didn't crashed ! :) ( only showed a back screen, but no crash :) )

My setup is 2 DisplayPort monitors on primary gpu and + 1 HDMI on secondary gpu.

If you need user testing just ping :) Thank you !
Comment 12 Zamundaaa 2020-09-09 22:44:57 UTC
Yes, that was the last version. The current one just crashes because it tries to render on displays it doesn't know about.

>If you need user testing just ping
Will do!
Comment 13 David Edmundson 2020-10-05 21:06:00 UTC
Git commit b50f7478769c1b50b48d5f0e9201a8e4b7e275ef by David Edmundson, on behalf of Xaver Hugl.
Committed on 05/10/2020 at 21:05.
Pushed by davidedmundson into branch 'master'.

Multi-GPU output support on Wayland

This commit sets up udev and the DrmBackend to list and use all GPUs.
Related: bug 417323

M  +1    -0    plugins/platforms/drm/CMakeLists.txt
M  +88   -262  plugins/platforms/drm/drm_backend.cpp
M  +7    -54   plugins/platforms/drm/drm_backend.h
A  +273  -0    plugins/platforms/drm/drm_gpu.cpp     [License: GPL(v2.0+)]
A  +111  -0    plugins/platforms/drm/drm_gpu.h     [License: GPL(v2.0+)]
M  +9    -7    plugins/platforms/drm/drm_object_crtc.cpp
M  +7    -1    plugins/platforms/drm/drm_object_crtc.h
M  +39   -36   plugins/platforms/drm/drm_output.cpp
M  +11   -4    plugins/platforms/drm/drm_output.h
M  +10   -8    plugins/platforms/drm/egl_gbm_backend.cpp
M  +3    -1    plugins/platforms/drm/egl_gbm_backend.h
M  +10   -9    plugins/platforms/drm/egl_stream_backend.cpp
M  +3    -1    plugins/platforms/drm/egl_stream_backend.h
M  +7    -5    plugins/platforms/drm/scene_qpainter_drm_backend.cpp
M  +3    -1    plugins/platforms/drm/scene_qpainter_drm_backend.h
M  +1    -1    plugins/platforms/fbdev/fb_backend.cpp
M  +47   -32   udev.cpp
M  +5    -2    udev.h

https://invent.kde.org/plasma/kwin/commit/b50f7478769c1b50b48d5f0e9201a8e4b7e275ef
Comment 14 Zamundaaa 2020-10-05 22:26:07 UTC
It's not quite fixed yet, that was the first of (probably) 3 commits.
Comment 15 Christoph Feck 2020-10-21 20:13:47 UTC
The status of this ticket doesn't match comment 14. Was the status change intended?
Comment 16 Zamundaaa 2020-10-22 21:38:11 UTC
Isn't VERIFIED UPSTREAM correct? Or is that for bugs in Qt and the like?

Btw, I just now got it working for Mesa drivers :D

I'll upload the commit to https://invent.kde.org/plasma/kwin/-/merge_requests/324 in a moment, if you could test it would be great!
Comment 17 Fervi 2020-10-25 12:03:35 UTC
Well, I have problems with the proper launch of KDE on Wayland. If others have problems it is good if they test it, because I do not know if I can run it.
Comment 18 Zamundaaa 2020-10-29 19:11:32 UTC
@Alexandre Pereira did you get around to test it? It would probably be best to verify it works on other hardware before it gets merged
Comment 19 Alexandre Pereira 2020-10-30 02:25:55 UTC
(In reply to Zamundaaa from comment #18)
> @Alexandre Pereira did you get around to test it? It would probably be best
> to verify it works on other hardware before it gets merged

Sorry, i didn't test your new work yet.
I tested the merge from D.E. but not your new work. Can I give feedback on saturday ?

just a note on your comment:
"So, the only issue with this patch that I have now is that VSync doesn't appear to work correctly on my Intel iGPU when used as a secondary GPU. It doesn't VSync on X either so it might just be a driver thing though.
A bit of testing would be nice, aside from that this patch is finished."

I have an amd card and intel as secondary. By default on xorg, it doesn't vsync ( and shows ... badly ). But with configuration of the intel card on xorg, and also on swaywm, there isn't any vsync issues with intel as secondary card ( being the intel secondary card, cpu integrated ).
Comment 20 Zamundaaa 2020-10-30 02:35:41 UTC
(In reply to Alexandre Pereira from comment #19)
> Sorry, i didn't test your new work yet.
> I tested the merge from D.E. but not your new work. Can I give feedback on
> saturday ?

You don't have to hurry.

> just a note on your comment:
> "So, the only issue with this patch that I have now is that VSync doesn't
> appear to work correctly on my Intel iGPU when used as a secondary GPU. It
> doesn't VSync on X either so it might just be a driver thing though.
> A bit of testing would be nice, aside from that this patch is finished."
> 
> I have an amd card and intel as secondary. By default on xorg, it doesn't
> vsync ( and shows ... badly ). But with configuration of the intel card on
> xorg, and also on swaywm, there isn't any vsync issues with intel as
> secondary card ( being the intel secondary card, cpu integrated ).

I also have a Intel iGPU as secondary. I'll look into it, would be nice to get rid of that tearing.
Comment 21 Christoph Feck 2020-10-30 04:26:30 UTC
Reopening according to comment 14.
Comment 22 Alexandre Pereira 2020-11-03 20:15:12 UTC
zamundaaa .... i haven't been able to test it.
I have been running stable version when 5.20 got released, and this weekend changing to git daily packages on opensuse, makes wayland not run, with error: kernel: kwin_wayland[1731]: segfault at 18 ip 00007fb4ce17127c sp 00007ffdba56e240 error 4 in KWinWaylandDrmBackend.so[7fb4ce14d000+26000]

just giving this feedback so that you don't think i didn't remembered :)
Comment 23 Zamundaaa 2020-11-09 01:42:03 UTC
> this weekend changing to git daily packages on opensuse

Git packages won't give you this branch anyways, and if you compile yourself (with kdesrc-build) they shouldn't even affect the result.
Comment 24 Alexandre Pereira 2020-11-09 04:31:31 UTC
(In reply to Zamundaaa from comment #23)
> > this weekend changing to git daily packages on opensuse
> 
> Git packages won't give you this branch anyways, and if you compile yourself
> (with kdesrc-build) they shouldn't even affect the result.

I did compile kwin with your branch ( not main git kwin ). it did compile correctly.

but what happens, and i tried going back to stable packages to confirm it. kwin 5.20 works in the wayland session (but without the extra gpu monitor ), but kwin in git kde packages doesn't. don't understand it. ( and i mean normal kwin, not your branch )

I will try with kdesrc-build, to see if it makes it work
Comment 25 Alexandre Pereira 2020-11-14 15:58:27 UTC
so i think i figured out what is happening:
on kwin master ( 5.21 )

it wasn't a problem with opensuse packaging. On kwin master, kwin wayland crashes if using the amdgpu kernel driver with amdgpu.dc=0. it works with amdgpu.dc=1. ( i have amdgpu.dc=0 because with amdgpu.dc=1 ... monitors switch order/placement randomly between reboots ).

I have two machines, one with a recent amd card that uses amdgpu driver and another with an old amd card that uses the radeon driver.

i haven't been able to launch kwin master on my intel cpu with an old amd card.

i was able to get some kind of backtrace but dunno if it helps:

#0  KWin::DrmGpu::updateOutputs() [clone .isra.0] (this=0x5604c1caca10) at /usr/src/debug/kwin5-5.20.80git.20201112T091457~f26eeb970-ku.22.1.x86_64/plugins/platforms/drm/drm_gpu.cpp:138
#1  0x00007fea4b621d54 in KWin::DrmBackend::updateOutputs() (this=<error reading variable: Cannot access memory at address 0x7fff7d25f7f0>)
    at /usr/src/debug/kwin5-5.20.80git.20201112T091457~f26eeb970-ku.22.1.x86_64/plugins/platforms/drm/drm_backend.cpp:351
#2  KWin::DrmBackend::updateOutputs() (this=<error reading variable: Cannot access memory at address 0x7fff7d25f7f0>) at /usr/src/debug/kwin5-5.20.80git.20201112T091457~f26eeb970-ku.22.1.x86_64/plugins/platforms/drm/drm_backend.cpp:344

well, all this above was with stock master kwin.
with your branch "wayland-multi-egl-backend", I have a crash at startup (like the above ) with the output:

No backend specified through command line argument, trying auto resolution
ASSERT failure in QVector<T>::at: "index out of range", file /usr/include/qt5/QtCore/qvector.h, line 455
"/usr/bin/kwin_wayland" ("--xwayland", "--exit-with-session=/usr/lib64/libexec/startplasma-waylandsession") exited with code 6
startplasmacompositor: Shutting down...
startplasmacompositor: Done.
Comment 26 Alexandre Pereira 2020-11-14 17:22:39 UTC
zamundaaa:

got it to work by commenting the code:

            /*if (c->isNonDesktop()) {
                delete c;
                continue;
            }*/


on plugins/platforms/drm/drm_gpu.cpp

with that code commented and working, I got both monitors ( the one on the amd card and the one on the intel igpu )
Comment 27 Alexandre Pereira 2020-11-14 18:01:00 UTC
more specificly, is this line of code: 

        return m_props.at(static_cast<int>(PropertyIndex::NonDesktop))->value();

on     kwin/plugins/platforms/drm/drm_object_connector.h
Comment 28 Zamundaaa 2020-11-14 18:48:04 UTC
Great to know that it works for you. How's the tearing?

And many thanks for that info, I fix it - and prevent similar problems with props not exposed by the driver in the future.
Comment 29 Alexandre Pereira 2020-11-14 19:01:07 UTC
Sorry to be almost hijacking this bug report, but i dunno where should I take this findings.

So, changing the code to:

```
bool isNonDesktop() const {
    qCDebug(KWIN_DRM) << "ALEXP PROPERTIES SIZE" << m_props.size();
        if (m_props.size() == 0)
            return false;

        return m_props.at(static_cast<int>(PropertyIndex::NonDesktop))->value();
    }
```

in the logging, it seems it calls that code once where the size of properties is 0. then the next time it calls it, its 2

This makes it work.
Comment 30 Alexandre Pereira 2020-11-14 19:02:23 UTC
about the tearing, its not great. it has more tearing that X11, with the following case:

If unconfigured X11, it seems to have the same or slightly better.
if X11 configured with:

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "DRI" "3"
  Option "TearFree" "true"
EndSection


it has worse tearing ( well, X11 with those configs has no visible tearing )
Comment 31 Zamundaaa 2020-11-14 21:03:19 UTC
> in the logging, it seems it calls that code once where the size of properties is 0. then the next time it calls it, its 2

It gets called once per GPU, so that's expected. I'll fix it properly, we should have proper checks for that anyways, for older kernel/driver versions etc that don't present us with certain properties.

The tearing is unfortunate but also not unexpected. Fixing that will likely have to wait for a little while as I have neither hardware to test nor any untested ideas anymore.
Comment 32 Alexandre Pereira 2020-11-14 22:49:24 UTC
> The tearing is unfortunate but also not unexpected. Fixing that will likely
> have to wait for a little while as I have neither hardware to test nor any
> untested ideas anymore.

btw as a more "scientific" way of analysing vsync, check:
https://www.vsynctester.com/

also, if is possible as a guide, swaywm does vsync perfectly.

Also, as a notice, using vsynctester.com, even the primary dedicated video card isn't having optimal vsync.

Anyway, since I now have your branch working again, I can now test as soon as you commit.
Comment 33 Zamundaaa 2020-11-14 23:56:13 UTC
>also, if is possible as a guide, swaywm does vsync perfectly.

I have already looked into that but didn't find any synchronisation code (and not in Mutter either).
I did now look again through relevant MRs though and finally found out why it works there. I think it will take a bit of effort to implement the required OpenGL contexts per GPU but will come with some upsides too. I'll keep you posted :)

>Also, as a notice, using vsynctester.com, even the primary dedicated video card isn't having optimal vsync.

That's planned to be fixed until 5.21: https://invent.kde.org/plasma/kwin/-/issues/22
Comment 34 Robert-André Mauchin 2020-12-04 02:53:15 UTC
I have a new laptop with NVidia dedicated and AMD integrated (Renoir). Both DP and HDMI are connected through the NVidia dedicated card and no external screen are detected. Is this the same issue? Is the patch would work too?
Comment 35 Robert-André Mauchin 2020-12-04 04:06:47 UTC
Tested it, sadly does not work for me.
Comment 36 Zamundaaa 2020-12-04 12:17:18 UTC
Yes it should but only with Noveau; the proprietary driver is still incapable of it. A developer from NVidia said that they are finally working on it but I have no idea when it will be ready.

When the driver is ready it will still probably require a bunch of code changes for KWin though, it would probably make sense to make a new bug report for it.
Comment 37 Robert-André Mauchin 2020-12-04 19:50:03 UTC
(In reply to Zamundaaa from comment #36)
> Yes it should but only with Noveau; the proprietary driver is still
> incapable of it. A developer from NVidia said that they are finally working
> on it but I have no idea when it will be ready.
> 
I've tried with Nouveau and my external screens are not detected either.
Comment 38 Zamundaaa 2020-12-05 00:55:32 UTC
Okay, then do please do make a new bug report for multi-monitor with NVidia
Comment 39 Bug Janitor Service 2021-01-28 22:36:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/642
Comment 40 Zamundaaa 2021-01-28 22:36:25 UTC
I potentially missed a very easy fix for the tearing problem... While I'm not entirely sure if that really does it, please do test!
Comment 41 Zamundaaa 2021-02-01 11:26:30 UTC
Good news, someone in another bug report already tested it and it does indeed fix it! Enjoy your tearing free secondary monitors in 5.21 :)
Comment 42 Zamundaaa 2021-02-01 11:27:12 UTC
Git commit 2c6d19fec1413244938bc997373e5f75df2c1ada by Xaver Hugl.
Committed on 01/02/2021 at 11:26.
Pushed by zamundaaa into branch 'master'.

Only release shared buffers right before the next frame

M  +0    -3    plugins/platforms/drm/abstract_egl_drm_backend.h
M  +8    -22   plugins/platforms/drm/egl_gbm_backend.cpp
M  +0    -1    plugins/platforms/drm/egl_gbm_backend.h

https://invent.kde.org/plasma/kwin/commit/2c6d19fec1413244938bc997373e5f75df2c1ada
Comment 43 Zamundaaa 2021-02-01 11:27:38 UTC
Git commit 27e7dba1c47a7ccaf3b66bbdb7ee0ef6eb4a7463 by Xaver Hugl.
Committed on 01/02/2021 at 11:27.
Pushed by zamundaaa into branch 'Plasma/5.21'.

Only release shared buffers right before the next frame


(cherry picked from commit 2c6d19fec1413244938bc997373e5f75df2c1ada)

M  +0    -3    plugins/platforms/drm/abstract_egl_drm_backend.h
M  +8    -22   plugins/platforms/drm/egl_gbm_backend.cpp
M  +0    -1    plugins/platforms/drm/egl_gbm_backend.h

https://invent.kde.org/plasma/kwin/commit/27e7dba1c47a7ccaf3b66bbdb7ee0ef6eb4a7463
Comment 44 Fervi 2021-03-23 12:09:29 UTC
@Zamundaaa

Reopening. The bug is partially fixed, but not fully (maybe you have an idea). I used a testing version of KDE Neon (to have some patches) and in Xorg all monitors (builded in laptop and external) works. On Wayland only build-in works. KDE now detects external monitor (and "use" it), but the screen goes to power-save mode (probably not receiving any data to draw).

https://0bin.net/paste/AwDd-2Ak#GPgERL0+xBNEOWMt0CdlpePC+TZ8xaC0vvSF62raL4v
Log
Comment 45 Zamundaaa 2021-03-27 17:09:04 UTC
It sounds like https://bugs.kde.org/show_bug.cgi?id=432707. I'm gonna need ~/.local/share/sddm/wayland-session.log to make sure
Comment 47 Zamundaaa 2021-03-28 21:16:56 UTC
It seems like it's indeed the same, probably caused by the discrete GPU not being able to scan out linear buffers. You can add your info to 432707, we'll track it there.
Comment 48 Nate Graham 2021-03-28 21:24:12 UTC

*** This bug has been marked as a duplicate of bug 432707 ***