Trying to run KDE 6 Plasma with Wayland....

Maxnix said:
Thank you, but I already know about that bug, and already have a patched version compiled locally.
Maybe it needs to be recompiled, will give a try.
Click to expand...
Be careful with the graphics stack - esp. mesa-libs and related stuff like libclc and spirv-llvm-translator. That stuff seems to prefer to be compiled with the same version of LLVM.

I tried to compile my way into KDE Plasma Wayland several times over, and sometimes parts of the graphics stack would not compile, so I had to do a pkg fetch on some of those libs. It turned out to be a bad move, at least for me, the graphics stack would fall apart and not work, and it was difficult to troubleshoot. My troubleshooting difficulties are at least in part because I don't know where to look to capture error messages when things crash, and graphics are an unwieldy beast.

My personal observation was that paying attention to the LLVM flavor in use made a difference for me. Right now, I'm just happy that amdgpu driver/firmware behaves for me.
 
Ok, boys (and girls), I just compiled my KDE compositor without all the nasty X11 stuff, and I got it to work. It's a thing of beauty. I spent hours on this, but it's done and done.

Basically, just compiled x11-wm/plasma6-kwin with a couple of flags (of course, it needed a few source modifications). Installed it. And launched my KDE manually - not via startplasma-wayland but via kwin_wayland with all the environment and the KDE services.

X11 exorcism complete. 👿

Note: it's not just X11 crap that needed to be excised but EIS as well - an additional very nasty parasitic code.
 
Notably, if you run pure KDE wayland compositor, session state save/restore will not work because their ksmserver is built as an XSMP server (X session management protocol). XSMP requires X11, and if you compile without X11, then you will not have any session save/restore. Not a biggie, but KDE people need to get real fast.
 
You will also lose out on all the non-purely Wayland themes, what a deal breaker! No more Adwaita. Only breeze and oxygen themes by default, can get more though!
 
Right now, my biggest complaint about this whole enchilada is that I can't turn my monitor off. I had to mess around in power management settings (in the systemsettings app) to never allow the machine to sleep or turn the screen off. Well, turns out I can't turn my monitor off manually, either - everything crashes, and I have to do a hard reboot to get anything going.

I think that this is more of a drm-kmod / graphics stack issue than a Wayland issue, because I've seen similar stuff happen under Xorg. To me, this does look like another nearly endless rabbit hole to explore, but it sure is affecting my Plasma Wayland experience.

How does that power management experience compare with other Wayland compositors / desktops?
 
astyle what gpu are you using and how is it connected with the screen (dp, hdmi, lvds, integrated)?

For me under X, with a radeon 780M (integrated on a ryzen 7 8745h, drm-6.12, connected via hdmi), the monitor blanks and suspends correctly. What sometimes happens is that after inputing the password X hangs but it only happens with xfce-screensaver (and/or lightdm), with xscreensaver I don't have issues.
 
fahrenheit said:
astyle what gpu are you using and how is it connected with the screen (dp, hdmi, lvds, integrated)?

For me under X, with a radeon 780M (integrated on a ryzen 7 8745h, drm-6.12, connected via hdmi), the monitor blanks and suspends correctly. What sometimes happens is that after inputing the password X hangs but it only happens with xfce-screensaver (and/or lightdm), with xscreensaver I don't have issues.
Click to expand...
My Ryzen 5 7600 has an iGPU, I'm using drm-6.12, with DisplayPort, and my monitor is a Gigabyte G27FC. I could potentially try using previous-gen drm-kmod, that's an idea worth trying.
 
So after an upgrade from 15.0 to 15.1 plasma wayland stopped working again for me.
It complains about no cards found despite the fact that /dev/dri/card0 is there.
Also sysctl hw.nvidiadrm.modeset displays "1".
 
elgrande said:
So after an upgrade from 15.0 to 15.1 plasma wayland stopped working again for me.
It complains about no cards found despite the fact that /dev/dri/card0 is there.
Also sysctl hw.nvidiadrm.modeset displays "1".
Click to expand...
Is your iGPU is disabled via UEFI firmware (or via legacy BIOS), or nonexistent, right?

If not, NVIDIA dGPU would be /dev/dri/card1, not /dev/dri/card0.

If yes, are you sure you've built your x11/nvidia-kmod*, graphics/nvidia-drm-*-kmod* and corresponding graphics/drm-*-kmod via ports using /usr/src/sys 100% in sync with your running kernel?
 
loveydovey said:
Ok, boys (and girls), I just compiled my KDE compositor without all the nasty X11 stuff, and I got it to work. It's a thing of beauty. I spent hours on this, but it's done and done.

Basically, just compiled x11-wm/plasma6-kwin with a couple of flags (of course, it needed a few source modifications). Installed it. And launched my KDE manually - not via startplasma-wayland but via kwin_wayland with all the environment and the KDE services.

X11 exorcism complete. 👿

Note: it's not just X11 crap that needed to be excised but EIS as well - an additional very nasty parasitic code.
Click to expand...

I still use startplasma-wayland to start Plasma, but an AI-generated patch prevents startplasma-wayland from automatically starting Xwayland.
 
T-Aoki said:
Is your iGPU is disabled via UEFI firmware (or via legacy BIOS), or nonexistent, right?

If not, NVIDIA dGPU would be /dev/dri/card1, not /dev/dri/card0.

If yes, are you sure you've built your x11/nvidia-kmod*, graphics/nvidia-drm-*-kmod* and corresponding graphics/drm-*-kmod via ports using /usr/src/sys 100% in sync with your running kernel?
Click to expand...
Ty!
Now it works (after building from ports).
I was thinking the -kmods repo should take care about that problem - obviously I was wrong 😅.
 
elgrande said:
Ty!
Now it works (after building from ports).
I was thinking the -kmods repo should take care about that problem - obviously I was wrong 😅.
Click to expand...
This is basically because kmods repo builder still does NOT build NVIDIA things other than x11/nvidia-kmod alone and need to be patient until the admins address why.

If usual kmod KBI is not changed and your x11/nvidia-kmod* and graphics/nvidia-drm-*-kmod* matches version in NVIDIA part and the latter also matches corresponding graphics/drm-*-kmod, it could load without complaining, but simply don't work as of LinuxKPI changes.


The description below could happen even after the kmods builder regression is addressed.

If the upgrade is done just before or after upgrades in NVIDIA driver ports, there can be time windows that version between main ports repo (non-kmod parts are built here only) and kmod repo, as of the timing on building upgraded ports.

And if the timing you've tried is the worst, means, "new patch release is released, you've upgraded to it, but kmod builders are not yet upgraded, and updates to LinuxKPI are somehow included", graphics/nvidia-drm-*-kmod* and graphics/drm-*-kmod at kmods repo could fail to work, as of LinuxKPI incompatibilities.

This is why I often (almost always) say it's safe to build kmod ports locally, especially when it depends on LinuxKPI.
 
This reminds me, is it possible to let the screen turn itself off automatically with NVidia drivers? I'm on AMD hardware, and I've noticed that I kind of have to keep the screen on at all times, and never let it turn off, even when I sleep. Otherwise, the whole machine crashes, and I'm forced into a hard reboot.

Is the situation similar with NVidia, or not?
 
I just wanted to share a fix I have discovered. I had the driver glitching with transparency and vertical lines all couple of hours.
This seems to have been fixed by setting setenv KWIN_DRM_NO_DIRECT_SCANOUT 1 before session start.
 
You must log in or register to reply here.
Back
Top