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

Well, seems like I'm closing in on the Spectacle showstopper, and progress has been made. Errors and versions got captured, so progress is there. So...

Plasma is at 6.3.3, Frameworks is at 6.12.0, and QT6 is at 6.8.2... (Commit references can be dug up at https://cgit.freebsd.org/ports/log/Mk/Uses/kde.mk.) Spectacle (graphics/plasma6-spectacle) is now part of Plasma components. Still using that /etc/make.conf flag I mentioned earlier. Only multimedia/libva is installed as a dependency while installing the KDE6 desktop. This is not enough for Spectacle, it does need multimedia/libva-utils.

Code: 
astyle@way-kde6:~ $ pkg info | grep libva  
libva-2.22.0                   VAAPI wrapper and dummy driver  
libva-utils-2.22.0             Collection of tests and utilities for VAAPI  
libva-vdpau-driver-0.7.4_10    VDPAU-based backend for VAAPI

Launching Spectacle from command line via /usr/local/bin/spectacle or just spectacle or dbus-launch spectacle makes no difference.

Code: 
astyle@way-kde6:~ $ spectacle    
On Wayland, Spectacle requires KDE Plasma's KWin compositor, which does not seem to  be available. Use Spectacle on KDE Plasma, or use a different screenshot tool.  
libva info: VA-API version 1.22.0  
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so  
libva info: va_openDriver() returns -1  
kpipewire_vaapi_logging: VAAPI: Failed to initialize display  
kpipewire_vaapi_logging: DRM device not found  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width"  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width"  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width"

Well, file /usr/local/lib/dri/radeonsi_drv_video.so doesn't exist! Small wonder Spectacle has a stubborn pink error that says "An error occurred while taking a screenshot"!

The directory /usr/local/lib/dri/ does have a file named radeonsi_dri.so. So, what if I try to symlink to the correctly named lib? That sometimes works, and can't hurt, right?

Code: 
# ln -s /usr/local/lib/dri/radeonsi_dri /usr/local/lib/dri/radeonsi_drv_video.so

The only real difference is that now we have a line about a libva error inside the launch trace for Spectacle:

Code: 
astyle@way-kde6:~ $ spectacle    
On Wayland, Spectacle requires KDE Plasma's KWin compositor, which does not seem to  be available. Use Spectacle on KDE Plasma, or use a different screenshot tool.  
libva info: VA-API version 1.22.0  
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so  
libva error: /usr/local/lib/dri/radeonsi_drv_video.so has no function __vaDriverInit_1_0
libva info: va_openDriver() returns -1  
kpipewire_vaapi_logging: VAAPI: Failed to initialize display  
kpipewire_vaapi_logging: DRM device not found  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width"  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width"  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width"

Running pkg which /usr/local/lib/dri/radeonsi_dri.so shows that the file was installed by graphics/mesa-dri, at v. 24.1.7_4. Upstream version is at 25.0.

Based on that, my thinking goes there's a couple possibilities:
- graphics/mesa-dri has a buggy process for compiling the radeonsi lib, which I do need for my hardware... Well, it had no issues under Xorg, though!
- libva needs to be told to use the correct radeonsi lib
 
astyle said:
- libva needs to be told to use the correct radeonsi lib
Click to expand...
Make your pick:

find /usr/ports -iname pkg-plist -exec grep radeonsi_dri.so {} +
/usr/ports/graphics/mesa-devel/pkg-plist:%%radeonsi%%lib/dri%%SUFFIX%%/radeonsi_dri.so
/usr/ports/graphics/mesa-dri/pkg-plist:%%radeonsi%%lib/dri/radeonsi_dri.so
/usr/ports/graphics/mesa-gallium-va/pkg-plist:@comment lib/dri/radeonsi_dri.so
/usr/ports/graphics/mesa-gallium-vdpau/pkg-plist:@comment lib/dri/radeonsi_dri.so
 
Tieks said:
Make your pick:

find /usr/ports -iname pkg-plist -exec grep radeonsi_dri.so {} +
/usr/ports/graphics/mesa-devel/pkg-plist:%%radeonsi%%lib/dri%%SUFFIX%%/radeonsi_dri.so
/usr/ports/graphics/mesa-dri/pkg-plist:%%radeonsi%%lib/dri/radeonsi_dri.so
/usr/ports/graphics/mesa-gallium-va/pkg-plist:@comment lib/dri/radeonsi_dri.so
/usr/ports/graphics/mesa-gallium-vdpau/pkg-plist:@comment lib/dri/radeonsi_dri.so
Click to expand...
Looking into this result, for graphics/mesa-devel and graphics/mesa-dri, radeonsi_drv.so is installed only if radeonsi in group option GALLIUM is enabled (including implicitly enabled by other options) into (by default) /usr/local/lib/dri/.

(If coinstallation is allowed, installed into /usr/local/lib/dri-devel/.)

And for graphics/mesa-gallium-vdpau, looking into its Makefile, option radeonsi is defined but explicitly excluded, thus, doesn't built for it.
 
astyle said:
Well, damn.

The flag in /etc/make.conf (CXXFLAGS+= -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2) still works, right-clicking is safe.

But... Looking at commit logs at https://cgit.freebsd.org/ports/log/x11-wm/plasma6-kwin/ :
The ticket PR 280638 is marked as closed, but it's definitely not solved. Last two comments (#11 and #12) on that ticket indicate that the screenshot issue still persists. No idea why the ticket was closed.

One more complaint that I have on this topic, screen locking works, but I can't leave it alone under Wayland - something just crashes, and I'm left with a blank screen. I have to SSH in from the side and reboot.

I'm glad I can launch with amdgpu from bare metal, but this is still a very fragile setup.

BTW, XDG_RUNTIME_DIR environment variable really has to be /var/run/user/1001, and not /var/run/xdg/astyle. This is another inconsistency that I've been running into. The former variant allows me to consistently and successfully start from metal. Unfortunately, I've had times when /var/run/user/1001 was randomly replaced by /var/run/xdg/astyle or completely disappeared, and env variables did not persist across reboots. 😭

Also, when I shut down, I get error messages about Pipewire crashing. Haven't captured those, but I think they might be relevant.

So yeah, progress has been made, but there's still a lot of ducks to get in a row.
Click to expand...
It seems to be sufficient to recompile graphics/qt6-wayland with CXXFLAGS+= -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 for the right-click bug to go away. Things feel fairly stable with the workaround.

I did not dive deep to understand the cause so I'm not suggesting that you should do this instead of recompiling everything, but it looks like it's working.

Bug from Gentoo's Bugzilla with some more information, if it was not referenced here already: https://bugs.gentoo.org/923292
 
Some other things that still do not work (for me at least):
  • Connecting to other monitors via HDMI - the new monitor is not detected and plasma (?) freezes in such a way that I cannot even switch to another tty to kill it and a hard reboot is needed.
  • Starting a Plasma wayland session from SDDM - editing /usr/local/share/wayland-sessions/plasma.desktop to use ck-launch-session successfully starts a session but Ctrl+C can kill it, all the keyboard input is visible in the underlying tty and can briefly be seen after resuming from sleep. I suspect that Plasma is somehow treated here as a terminal application, though I'm not sure at the moment what exactly that could mean.
  • Briefly after waking up from sleep and typing in the password another sleep happens. Not sure if that is specific to my laptop.
 
Is it possible to use Plasma on Wayland in a VMware virtual machine?
My experience:
VMware 17 on Windows, on that machine FreeBSD 14.2 with KDE Plasma 6.3.3 on x11. KDE runs on x11 without any issues.
I followed a video manual on installing Wayland, all packages installed without any errors.
KDE starts up manually (via startx), but:
1) the screen resolution is 1024*768 and cannot be changed inside KDE;
2) KDE freezes (or crashes?) with a black screen after a right click on the desktop.
Are these known issues?
KDE on Wayland does not start at all via SDDM. What should I change in the config files?
 
Post # 526 documents what happens when I have graphics/mesa-dri installed. This is the default port that is supposed to provide the /usr/local/lib/dri/radeonsi_drv_video.so that libva (provided by multimedia/libva-utils) is looking for. When the radeonsi_drv_video.so is missing, libva throws errors, and Spectacle doesn't work. And symlinking doesn't help.

graphics/mesa-gallium-va did rectify driver errors that graphics/mesa-dri showed. As in, it installed a proper /usr/local/lib/dri/radeonsi_drv_video.so that was NOT a symlink, and libva did like that.
Code: 
astyle@way-kde6:~ $ export KWIN_SCREENSHOT_NO_PERMISSION_CHECKS=1  
astyle@way-kde6:~ $ spectacle  
On Wayland, Spectacle requires KDE Plasma's KWin compositor, which does not seem to  
be available. Use Spectacle on KDE Plasma, or use a different screenshot tool.  
libva info: VA-API version 1.22.0  
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so  
libva info: Found init function __vaDriverInit_1_22  
libva info: va_openDriver() returns 0  
kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 24.1.7 for AMD Radeon Graphics (  
radeonsi, raphael_mendocino, LLVM 18.1.8, DRM 3.49, 14.2-RELEASE) in use for device  
"/dev/dri/renderD128"  
libva info: VA-API version 1.22.0  
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so  
libva info: Found init function __vaDriverInit_1_22  
libva info: va_openDriver() returns 0  
libva info: VA-API version 1.22.0  
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so  
libva info: Found init function __vaDriverInit_1_22  
libva info: va_openDriver() returns 0  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBa  
r: Binding loop detected for property "width"  
libva info: VA-API version 1.22.0  
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so  
libva info: Found init function __vaDriverInit_1_22  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBa  
r: Binding loop detected for property "width"  
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBa  
r: Binding loop detected for property "width"  
  
libva info: va_openDriver() returns 0  
QThreadStorage: Thread 0x29fa6703a2e0 exited after QThreadStorage 9 destroyed
The error capture did show some other issues:
- Dump trace shows incorrect device (/dev/dri/renderD128), should be (/dev/dri/0).
- There's also a weird 'Binding Loop' error: qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBar: Binding loop detected for property "width", and it gets repeated.

graphics/mesa-gallium-vdpau had an exact repeat of the issues and errors documented for graphics/mesa-dri, down to absence of the correct .so file.

But for graphics/mesa-devel, it was a different story, and that's for my next post. Well, it also was ultimately no good for Spectacle, Spectacle still doesn't work.

BTW, the versions involved:
 
Trying graphics/mesa-devel was a bit of a challenge: the /usr/local/lib/dri/radeonsi_drv_video.so (as provided by this port) is supposed to be a symlink to
/usr/local/lib/libgallium_dri-devel.so! I had to create the symlink manually, because the port installed to /usr/local/lib/dri-devel/radeonsi_drv_video.so.

Code: 
On Wayland, Spectacle requires KDE Plasma's KWin compositor, which does not seem to
be available. Use Spectacle on KDE Plasma, or use a different screenshot tool.
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libEGL warning: egl: failed to create dri2 screen
qt.qpa.wayland: Failed to initialize EGL display 3001
libva info: va_openDriver() returns 0
kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 25.1.0-devel for AMD Radeon Grap
hics (radeonsi, raphael_mendocino, LLVM 18.1.8, DRM 3.49, 14.2-RELEASE) in use for d
evice "/dev/dri/renderD128"
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/local/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBa
r: Binding loop detected for property "width"
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBa
r: Binding loop detected for property "width"
qrc:/qt/qml/org/kde/spectacle/private/Gui/DialogPage.qml:164:13: QML NavigationTabBa
r: Binding loop detected for property "width"

QRhiGles2: Failed to create temporary context
QRhiGles2: Failed to create context
Failed to create RHI (backend 2)
Failed to initialize graphics backend for OpenGL.

Well, even with symlink issue resolved, there's still some things from that dump that I see as important, because they were NOT present earlier:
Code: 
libEGL warning: egl: failed to create dri2 screen
qt.qpa.wayland: Failed to initialize EGL display 3001

And it still tries to use the wrong device (/dev/dri/renderD128 instead of /dev/dri/0)

Also, with that, Spectacle did crash (which did NOT happen when other Mesa ports were the ones which provided the radeonsi_drv_video.so.

And now... the version of graphics/mesa-devel involved on my machine is 25.0.b.2145... I checked back in ports, and since then, there was some updates, I can see that the latest version of mesa-devel is at 25.0.b.2739. This has me curious - did those updates resolve the screenshot errors? graphics/mesa-dri has not been touched since January of 2025.
 
Andriy said:
Regarding

Please see PR 286313.
Somebody from nvidia finally heard about it and acted.
Click to expand...
Unfortunatey, all versions available for now are released BEFORE his comment. So we need to wait for now. As I'm not a nvidia insider, don't know when it comes available.

Now we (who are working on related ports) are discussing about creating -devel variant for New Feature Branch (NFB) of drivers. If the version having the features is released as NFB of drivers, it would be the time we actually start working on it.

Note that Beta Branch of the drivers are out of scope, but would be the trigger for us to start investigating for upcoming NFB/Production versions.

Now? As latest NFB of the driver is older than Production Branch of driver.
So not the time to work on it. And the latest Beta Branch of driver (575.51.02) can be built by overriding version as usual without special care.
 
Hi everyone,

I realize I might be treading familiar ground here, but I think it would be genuinely helpful to have a clear, step-by-step base guide on how to go from a fresh FreeBSD 14 (or 15) installation to a "working" KDE 6 desktop running on Wayland.

I'm far from as experienced as many of you here, so having some concrete instructions could really help users like me get up and running more confidently. I understand that KDE 6 with Wayland is still in a very early and experimental stage on FreeBSD, and likely comes with a number of limitations or broken features. That said, I’d still love to take it for a spin.

Currently, the available information online, across YouTube videos, forum posts, and other sources, feels quite fragmented. If a guide like this already exists, I’d really appreciate a link or pointer to it.

Thanks in advance!

Kind regards,
B.
 
DeWaard said:
Hi everyone,

I realize I might be treading familiar ground here, but I think it would be genuinely helpful to have a clear, step-by-step base guide on how to go from a fresh FreeBSD 14 (or 15) installation to a "working" KDE 6 desktop running on Wayland.

I'm far from as experienced as many of you here, so having some concrete instructions could really help users like me get up and running more confidently. I understand that KDE 6 with Wayland is still in a very early and experimental stage on FreeBSD, and likely comes with a number of limitations or broken features. That said, I’d still love to take it for a spin.

Currently, the available information online, across YouTube videos, forum posts, and other sources, feels quite fragmented. If a guide like this already exists, I’d really appreciate a link or pointer to it.

Thanks in advance!

Kind regards,
B.
Click to expand...
Wayland is possible with KDE 6 plasma, but it's not stable yet. Spectacle is having issues. Waiting for Plasma 6.4 to be out later this month to see if Spectacle works in this release. As things stand now, it's kind of difficult to control what happens when the screen times out after inactivity, and it's so bad, that it's a major showstopper. Once things are under control and reproducible, that's when it will be even possible to write any documentation and setup instructions.

I'd say that trying to set it up right now, as things stand, is a waste of time unless you're willing to participate in the development process, and report whether or not the patches work, and what got fixed/broken since the previous release.

People are spinning up VMs and using spare hardware for this right now. It's just not suitable as a daily driver yet.
 
  • Like
Reactions: drr
After latest upgrade of Qt packages to 6.9.1, Plasma is failing to start. kwin_wayland is failing to find a symbol:
Bash: 
ld-elf.so.1: /usr/local/bin/kwin_wayland: Undefined symbol "_ZN20QGenericUnixServicesC1Ev@Qt_6_PRIVATE_API".
EDIT: Reinstalling plasma fixed the issue. (?)
 
Update:

Plasma 6.4 compiled. Once the line dbus_enable="YES" is in /etc/rc.conf, then the KDE Wayland session can be reliably started with
ck-launch-session /usr/local/lib/libexec/plasma-dbus-run-session-if-needed startplasma-wayland.

For Spectacle to work properly:

It does need multimedia/libva-utils (even though it's not specified as a dependency for Spectacle), and graphics/mesa-gallium-va, because the last one provides the /usr/local/lib/dri/radeonsi_drv_video.so. Once those were installed, Spectacle stopped complaining that it can't find the graphics drivers.

It also needs the following line in /etc/fstab: (Logic from PR 280638, a closed ticket that still offered a hint as to what was missing)
Code: 
proc                    /proc   procfs  rw      0       0
Without this ☝️, the libEGL error that I talked about in post #535 won't go away. The Handbook currently does NOT even mention the need for that line to be in /etc/fstab, but for KDE Wayland, it may need to come back.

Trying graphics/mesa-devel for the same /usr/local/lib/dri/radeonsi_drv_video.so: My ports snapshot had version 25.1.b.2584, which did not compile (failed at linking stage). Package fetched from Latest repo was at v. 25.1.b.2820, and it had EVERYTHING on. Switching between graphics/mesa-gallium-va and graphics/mesa-devel made no difference. /usr/local/lib/dri/radeonsi_drv_video.so worked fine.

1750546454136.png

Yep, taken with Spectacle on the system.

Well, with this, I'm pretty much happy. Everything else can be considered a paper cut from this point out:
Konqueror compiles, but doesn't like Wayland, and crashes.

The biggest paper cut here, though, is power management - if the screen times out and turns off, there's no good way to resume (that I know of) short of rebooting. If anyone knows how to fix that, please post here!
 
astyle said:
proc /proc procfs rw 0 0
Click to expand...
Yes, this thing is needed even for tiling under Wayland. Classic already. I always take this into account.
astyle, do you have this in your config?
Code: 
tmpfs /tmp tmpfs rw,mode=01777 0 0
I saw in one manual that it is recommended for Wayland in general.
 
USerID said:
Yes, this thing is needed even for tiling under Wayland. Classic already. I always take this into account.
astyle, do you have this in your config?
Code: 
tmpfs /tmp tmpfs rw,mode=01777 0 0
I saw in one manual that it is recommended for Wayland in general.
Click to expand...
I will try that sometime soon.

I just now discovered another showstopper, and that one, I have no idea how to deal with: Power management.

I left the screen locked overnight. Turned off just the monitor. Went to sleep. In the morning, I turned the monitor back on, but both keyboard and mouse were unresponsive. Under Xorg, we have some kind of daemon to keep those basic connections alive, don't we? And under Wayland, screen locker is the next showstopper that needs to be addressed. Dunno if that was accomplished under Linux already or not.

I compiled everything from scratch using the flag that Oleg_NYC told me about awhile ago earlier in this thread.

I just don't want to reboot the computer every time I step away overnight or even for 5-10 minutes. 😭

This is another thing that is probably tied to proper interaction with the GPU drivers, just like Spectacle was. All I can do is compile and complain out loud.
 
Update: the tmpfs hack made no difference to the screenlocker. Something else needs to be done so that kscreenlocker works properly.

Update 2, 30 minutes later: x11/sddm compiled, and works fine to start the Plasma Wayland session. I guess this is thanks to the fact that Plasma Wayland can be started reliably as described in post #541. SDDM issues the exact same command to log me into the Plasma Wayland session.

I would not declare this stuff to be a daily driver yet - there's still a lot of details that need to reach parity with X11 KDE session first. But it's nice to see tangible progress.
 
"Found 0 GPUs" usually means /dev/dri/card0 is missing. On AMD/Intel it is provided by graphics/drm-kmod and on NVIDIA is provided by graphics/nvidia-drm-kmod with hw.nvidiadrm.modeset=1 in /boot/loader.conf. Maybe also try hw.nvidia.registry.EnableGpuFirmware=1 just in case.

For comparison, Xorg can work without DRM drivers or use proprietary API via /dev/nvidia0.
 
LibreQuest said:
I followed your suggestions but the same error persists. :/
Click to expand...
I'd think that a good test would be to first get a basic Xorg with TWM to even show up on your RTX 4060. If that is successful and reliable, then you're ready to see if Wayland can be given a go on the same hardware. It's OK, the two can live in the same machine and not fight ;)
 
You must log in or register to reply here.
Back
Top