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
 
- libva needs to be told to use the correct radeonsi lib
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
 
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
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.
 
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.
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.
 
Back
Top