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.
 
You must log in or register to reply here.
Back
Top