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

I found the kde plasma development thread 😂 nice

I don’t think you guys want to know what I’ve done so far. Will read up on the thread
 
I managed a hackable launch of KDE Plasma Destop version 6.4.5 + Wayland from the command line.

It isn't where I want it to be as you can see here. Screen resolution is 4K 3480x2160 with touch screen. Still catching up on the thread. We love our FreeBSD screenshots 😁
Screenshot_20251226_170413.png
 
Well, an update: x11-fm/konqueror has NOT been ported to Wayland. It crashes and leaves a core dump in a Wayland session, but starts properly in an Xorg session. Not a complete showstopper, but still a major annoyance.

Does anyone have a good hack to properly launch Konqueror on Wayland? Like with an XWayland shim or something like that?
 
astyle said:
Well, an update: x11-fm/konqueror has NOT been ported to Wayland. It crashes and leaves a core dump in a Wayland session, but starts properly in an Xorg session. Not a complete showstopper, but still a major annoyance.

Does anyone have a good hack to properly launch Konqueror on Wayland? Like with an XWayland shim or something like that?
Click to expand...
Well, as a datapoint, Konqeror works perfectly fine for me (nvidia-drm (with patched linuxkpi), konq 25.12.0, plasma/frameworks 6.4.5/6.18.0, everything built from ports).

A long time ago I too had problems with apps using qtwebengine on wayland (like konqueror) - even on Linux. Do for example kmail/akregator/falkon crash on startup as well? If yes, maybe starting konq with QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu-compositing" can be worth a try.
 
borsi1 said:
Do for example kmail/akregator/falkon crash on startup as well? If yes, maybe starting konq with QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu-compositing" can be worth a try.
Click to expand...
Yeah, they do. Falkon and KHelpCenter.

Oh, and one more thing that seems to be KDE Wayland-related, but I don't have a good idea of how to nail it down:

If I leave a KDE Wayland session specifically idle for a long enough time (like overnight or longer than 24 hours), the lockscreen activates, and then something crashes underneath all that. I tried an animated lockscreen, I tried enabling seatd - nothing worked. I do get an exact timestamp of when it happens, because the lockscreen shows a frozen clock. For example, one of my crashes happened just before 1 am, and I wake up at 6 am to discover that the screen is frozen, and I can't just wiggle my mouse and type in my password.

Today, though, I had KTorrent actively running overnight, and that seems to have helped, nothing crashed in my Plasma Wayland session. This has me thinking about memory leaks, but once again, I just don't have a good way off the top of my head on how to nail it down, which logs I should be looking through for the timestamps of crashes. If anyone has some troubleshooting tips for me, please post here!

Well, my GPU is AMD (as screenies from my earlier posts in this thread show).
 
Update: Nope, still crashes. Asks me to "Restore Previous Session", which I don't have, and then dumps core and the following text to stderr:
Code: 
kf.windowsystem: virtual void KX11Extras::connectNotify(const QMetaMethod &) may only be used on X11
kf.windowsystem: static void KX11Extras::setOnActivities(WId, const QStringList &) may only be used on X11
kf.parts: KPluginMetaData(name:"Okular", plugin-id:"okularpart") still defined ServiceTypes - this is deprecat
ed in favor of providing a  "Capabilities" list in the "KParts" object in the root of the metadata
kf.parts: KPluginMetaData(name:"Gwenview Image Viewer", plugin-id:"gvpart") still defined ServiceTypes - this 
is deprecated in favor of providing a  "Capabilities" list in the "KParts" object in the root of the metadata
kf.parts: KPluginMetaData(name:"Terminal Emulator", plugin-id:"konsolepart") still defined ServiceTypes - this
 is deprecated in favor of providing a  "Capabilities" list in the "KParts" object in the root of the metadata
kf.parts: ServiceType "inode/directory" from KPluginMetaData(name:"Terminal Emulator", plugin-id:"konsolepart"
) is not a known value that can be mapped to new Capability enum values
kf.parts: ServiceType "TerminalEmulator" from KPluginMetaData(name:"Terminal Emulator", plugin-id:"konsolepart
") is not a known value that can be mapped to new Capability enum values
kf.parts: KPluginMetaData(name:"Embedded Advanced Text Editor", plugin-id:"katepart") still defined ServiceTyp
es - this is deprecated in favor of providing a  "Capabilities" list in the "KParts" object in the root of the
 metadata

[1]   Trace/BPT trap (core dumped) konqueror QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu-compositing

I do have all the referenced KParts installed, like Okular, Konsole, etc. A bit frustrating, because I do like reading the manpages in Konqueror, rather than Konsole... and the fact that under Xorg, I don't have those 2 issues.

The part about things just crashing under the lockscreen - I merely described what is visible to me. The crashes may have nothing to do with Wayland stuff, but it's certainly a showstopper here.

This is all happening on my Lenovo Thinkbook 14 laptop. I have a different laptop (Asus ROG Zephyrus AMD Advantage) , where I was actually unable to get a KDE Wayland session going (or even Xorg, for that matter!) but Wayfire functions just fine, and doesn't crash. Well, under Wayfire, I can't use Spectacle, because it's a different compositor. But under Wayfire, Konqueror crashes and dumps core, as well, but with compositor messages that strongly resemble earlier (like from about a year ago) attempts to launch a KDE Wayland session at all. Unable to find appropriate screen, and to load proper plugins.
 
astyle said:
Update: Nope, still crashes. Asks me to "Restore Previous Session", which I don't have, and then dumps core and the following text to stderr:
Code: 
kf.windowsystem: virtual void KX11Extras::connectNotify(const QMetaMethod &) may only be used on X11
kf.windowsystem: static void KX11Extras::setOnActivities(WId, const QStringList &) may only be used on X11
kf.parts: KPluginMetaData(name:"Okular", plugin-id:"okularpart") still defined ServiceTypes - this is deprecat
ed in favor of providing a  "Capabilities" list in the "KParts" object in the root of the metadata
kf.parts: KPluginMetaData(name:"Gwenview Image Viewer", plugin-id:"gvpart") still defined ServiceTypes - this 
is deprecated in favor of providing a  "Capabilities" list in the "KParts" object in the root of the metadata
kf.parts: KPluginMetaData(name:"Terminal Emulator", plugin-id:"konsolepart") still defined ServiceTypes - this
 is deprecated in favor of providing a  "Capabilities" list in the "KParts" object in the root of the metadata
kf.parts: ServiceType "inode/directory" from KPluginMetaData(name:"Terminal Emulator", plugin-id:"konsolepart"
) is not a known value that can be mapped to new Capability enum values
kf.parts: ServiceType "TerminalEmulator" from KPluginMetaData(name:"Terminal Emulator", plugin-id:"konsolepart
") is not a known value that can be mapped to new Capability enum values
kf.parts: KPluginMetaData(name:"Embedded Advanced Text Editor", plugin-id:"katepart") still defined ServiceTyp
es - this is deprecated in favor of providing a  "Capabilities" list in the "KParts" object in the root of the
 metadata

[1]   Trace/BPT trap (core dumped) konqueror QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu-compositing

I do have all the referenced KParts installed, like Okular, Konsole, etc. A bit frustrating, because I do like reading the manpages in Konqueror, rather than Konsole... and the fact that under Xorg, I don't have those 2 issues.

The part about things just crashing under the lockscreen - I merely described what is visible to me. The crashes may have nothing to do with Wayland stuff, but it's certainly a showstopper here.

This is all happening on my Lenovo Thinkbook 14 laptop. I have a different laptop (Asus ROG Zephyrus AMD Advantage) , where I was actually unable to get a KDE Wayland session going (or even Xorg, for that matter!) but Wayfire functions just fine, and doesn't crash. Well, under Wayfire, I can't use Spectacle, because it's a different compositor. But under Wayfire, Konqueror crashes and dumps core, as well, but with compositor messages that strongly resemble earlier (like from about a year ago) attempts to launch a KDE Wayland session at all. Unable to find appropriate screen, and to load proper plugins.
Click to expand...

Just to make sure: you have set it as an environment variable, right? Looking at the backtrace it kind of looks like a parameter.
 
Librewolf has been fairly stable for web browsing on this setup.

I disabled sddm autostart at boot time. My method of troubleshooting is process of elimination. This helps me eliminate anything in the kde build that is crashing.

So I manually launch kde plasma desktop from the command line. I know this isn’t what everyone seeks for a stable desktop environment but it works for me.

From here I launch the de with the following commands
sh: 
sudo kldload i915kms # my specific GPU driver

. ~/.xinitrc

# you can alias these commands at ~/.shrc
# I set mine to 1. driver and 2. kde
 
rcbsdpge said:
Librewolf has been fairly stable for web browsing on this setup.

I disabled sddm autostart at boot time. My method of troubleshooting is process of elimination. This helps me eliminate anything in the kde build that is crashing.

So I manually launch kde plasma desktop from the command line. I know this isn’t what everyone seeks for a stable desktop environment but it works for me.

From here I launch the de with the following commands
sh: 
sudo kldload i915kms # my specific GPU driver

. ~/.xinitrc

# you can alias these commands at ~/.shrc
# I set mine to 1. driver and 2. kde
Click to expand...
You realize that the whole point of this thread is to wean ourselves off Xorg and related stuff like ~/.xinitrc... and that KDE plans to go Wayland-only pretty soon. And BTW, SDDM now works to launch both Xorg and Wayland sessions for KDE, I mentioned that earlier in this thread.

And now for an update from my end of things: With KTorrent actively running in my Plasma Wayland session, I have not had a crash like I described earlier in post #730 just a couple days ago... I can actually leave my session alone, overnight, and it will not crash underneath the lockscreen... go figga.

I actually had very similar crashes even without SDDM's involvement.
 
A rather unfortunate update, from another Forums thread: Thread freebsd-15-probably-will-include-kde-as-de-installtion-option.98635.

Start reading at post #101:
duncan_bayne

Post in thread 'FreeBSD 15 probably will include KDE as DE installtion option'

Is this still likely to happen given KDE seems to be dropping FreeBSD support?

invent.kde.org

Drop code for FreeBSD support (e78f33ae) · Commits · Plasma / Plasma Login Manager · GitLab

We rely on systemd/logind, so FreeBSD is not supported
invent.kde.org invent.kde.org
  • Thanks

Long story short, some FreeBSD-related code did get dropped. This probably means that the patch(es) to re-add that code will need to be maintained in the Ports Collection tree.

And, in other news, my Wayland session finally crashed, even with KTorrent running. Those crashes are a showstopper...
😭
 
itstotallyme said:
Does anybody know what would cause SDDM to simply not show any Wayland option on the login screen, for FreeBSD 15.0?
Click to expand...
Usually, a reboot after a fresh install solves this. KDE packages are compiled with Wayland support, but sometimes, some config files need to be re-read. Maybe your sddm.conf has the Wayland option deleted by accident.
 
Sadly, a reboot didn't fix it! Could it be related to me running FreeBSD in a Qemu virtual machine? The X11 session is using llvmpipe as the graphics backend. I think I managed to find the config file, /usr/local/etc/sddm.conf, this is how it looks like:
Screenshot_20260127_164439.png
 
Hm any suggestion what I should be doing to fix this? I'm a bit of a BSD noob and on Linux have been using Wayland forever, so I don't know what you mean with ~/.xinitrc sorry! I would be happy to ditch the X11 session entirely. Wayland seems like a better fit for my usual workflow.
 
rcbsdpge: This thread is about getting Plasma to run on Wayland, which does mean trying to wean ourselves off Xorg-related stuff like ~/.xinitrc...

itstotallyme: Do you have a directory whose full path is /usr/local/share/wayland-sessions/? It should have a filename called plasmawayland.desktop. Any login manager you install should be able to see it and offer a Wayland sessions. If you don't have that file, it may need to be created by hand. Can you do the research for the contents of what's supposed to go into that file?
 
Found this via phoronix.com today:

This Week in Plasma: fixing all the things

Welcome to a new issue of This Week in Plasma! This week the Plasma team focused almost entirely on bug fixing. And let’s let the results speak for themselves: we fixed 18 high and very high priority Plasma bugs, or 28% of all open ones! Lots of polishing for Plasma 6.6 to make it a great release.
blogs.kde.org blogs.kde.org
This blog entry does seem to talk about the same crashes that I complained about in this thread. This gives me hope that Wayland Plasma is stabilizing. No, I still have no idea how to troubleshoot the crashes on my end of things, but the visible symptoms (crashes) being described - they do sound very familiar.

Makes me look forward to Plasma 6.6, along with the new Plasma Login Manager...
 
astyle said:
Do you have a directory whose full path is /usr/local/share/wayland-sessions/?
Click to expand...
I do, I have that directory and that file:
Screenshot_20260127_210701-1.png

Is there perhaps something wrong with it, that causes the session not to show up?

I use this FreeBSD VM mainly for personal testing since I develop open-source software and I would love to support FreeBSD, especially FreeBSD+Wayland. So other than some KDE styling and using syncthing to keep some personal data up-to-date that sits also on my Linux machines, I haven't really done any deep modifications. I'm still learning FreeBSD!
 
astyle said:
rcbsdpge: This thread is about getting Plasma to run on Wayland, which does mean trying to wean ourselves off Xorg-related stuff like ~/.xinitrc...
Click to expand...
Unless anyone here is actively contributing to kde x11 or Wayland

FreeBSD is ‘do whatever you want’

And technically you can run Wayland on X11 - I didn’t build broken desktop environments
 
itstotallyme said:
I do, I have that directory and that file:
View attachment 25140
Is there perhaps something wrong with it, that causes the session not to show up?

I use this FreeBSD VM mainly for personal testing since I develop open-source software and I would love to support FreeBSD, especially FreeBSD+Wayland. So other than some KDE styling and using syncthing to keep some personal data up-to-date that sits also on my Linux machines, I haven't really done any deep modifications. I'm still learning FreeBSD!
Click to expand...
Well, have you tried starting Plasma Wayland from command-line? the plasmawayland.desktop file contains the following command:
/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-wayland... This is supposed to be the correct and standard command to start a Plasma Wayland session on FreeBSD.

And, I just remembered: One more thing to try: (as root, assuming that SDDM is enabled in your /etc/rc.conf)
Code: 
# service sddm restart

As for Plasma Login Manager, my own understanding is that it's supposed to depend on logind, rather than systemd. I probably should do some digging to confirm for sure, rather than just reading simple statements that [claim systemd dependency, with no other info to really substantiate that claim].

rcbsdpge said:
Unless anyone here is actively contributing to kde x11 or Wayland

FreeBSD is ‘do whatever you want’

And technically you can run Wayland on X11 - I didn’t build broken desktop environments
Click to expand...
I have been actively testing Plasma Wayland, and reporting on the progress in this thread. Hell, I even tested some area 51 code in there to make sure a painful bug is solved by a non-intuitive patch.

FreeBSD is not exactly 'do whatever you want'. The idea is to make sure that things are reproducible and stable. Just because something works somewhat, unpredictably, due to an awkward hack, that doesn't mean that the hack is the correct way to do it. This is why Porter's Handbook exists, it's got excellent documentation of what code written for FreeBSD is supposed to be like.
 
You must log in or register to reply here.
Back
Top