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)
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`
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
It seems it is a low level issue, at Wayland level it seems or wayland driver.
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".
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/243
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.
(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
@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 :)
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.
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
(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 !
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!
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
It's not quite fixed yet, that was the first of (probably) 3 commits.
The status of this ticket doesn't match comment 14. Was the status change intended?
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!
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.
@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
(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 ).
(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.
Reopening according to comment 14.
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 :)
> 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.
(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
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.
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 )
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
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.
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.
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 )
> 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.
> 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.
>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
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?
Tested it, sadly does not work for me.
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.
(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.
Okay, then do please do make a new bug report for multi-monitor with NVidia
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/642
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!
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 :)
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
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
@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
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
@Zamundaaa https://0bin.net/paste/vL4SoWkC#Ztq+wB20+q01dgPucQVA0thFyYiOhUfqoGvvGN3B7zK
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.
*** This bug has been marked as a duplicate of bug 432707 ***