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

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
I have tried it now. I went to the TTY, stopped SDDM, and then ran this command
Code:
/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-wayland
on the TTY as my non-root user that is in the video group (let me know if that's correct). Sadly I only got some wall of text and it didn't launch. I redirected the command output into a file and attached it!

So I guess while the command exists, it doesn't seem to be working right for some reason.
 

Attachments

I have tried it now. I went to the TTY, stopped SDDM, and then ran this command
Code:
/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-wayland
on the TTY as my non-root user that is in the video group (let me know if that's correct). Sadly I only got some wall of text and it didn't launch. I redirected the command output into a file and attached it!

So I guess while the command exists, it doesn't seem to be working right for some reason.
Having the non-root user in video group is a correct move in any event.

Off the top of my head, all I can think of is that Plasma Wayland is not playing well with virtualized hardware that the FreeBSD guest can show it. I know for a fact that Plasma/Xorg plays well with that same base setup. This whole thread is about making Plasma Wayland play well with the hardware as FreeBSD can present it. It contains nuggets of useful info, what to pay attention to and fix. And, itstotallyme , your errors do look very similar to the stuff that was discussed earlier (like 2024) in this thread.

Just goes to show that Plasma Wayland is still a rather experimental toy, and not something that is reliably stabilized/automated to the point that RTFMing is all it takes to get it to work right in just about any situation, be it on metal or in a VM.
 
So you think this might e.g. be some problem of it trying to use the real GPU (inaccesible) rather than llvmpipe, inside Qemu?

Interesting. 😮 Thanks for taking a look!
 
So you think this might e.g. be some problem of it trying to use the real GPU (inaccesible) rather than llvmpipe, inside Qemu?

Interesting. 😮 Thanks for taking a look!
I don't have Qemu experience, only VirtualBox. But if a GPU is virtualized, then yeah, it's gonna be llvmpipe.

Also, in a somewhat unrelated matter, I'm beginning to think that maybe a working suspend/resume under FreeBSD is something that Plasma Wayland on FreeBSD would really benefit from.
 
Why are the kde & plasma6-plasma packages not available in latest for -STABLE?

Code:
FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
 
Why are the kde & plasma6-plasma packages not available in latest for -STABLE?

Code:
FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
What does that have to do with making sure the port runs correctly on Wayland? This thread is about addressing papercuts and showstoppers, and which versions they apply to. Packaging issues like this are best addressed in the Forums section titled "Installation and Maintenance of Ports and Packages". You'll find it on the front page of the Forums.
 
Best part? SDDM friggin' works to start Plasma Wayland session! Oh, and the issues with power management that I complained about in November? resolved! Session gets restored, no need to reboot, keyboard connection remains.
How to configure SDDM to start this session?
This
Code:
Exec=/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-wayland
does not work.
 
plasmashell is spiking at 99% CPU usage ever since I upgraded to 6.6.2 (FreeBSD 15). Anybody hitting the same?
I'm experiencing the same. But not only plasmashell, sddm too: according to truss output both seems to be in a loop executing fstatat() on four files (happens with both Xorg and Wayland session):
  • /etc/TZ
  • /etc/localtime
  • /etc/timezone
  • /var/db/zoneinfo
After a while sddm stops this loop, but plasmashell doesn't. I'm attaching the file with the output for plasmashell, just in case this could be useful to someone.

P.S. If in truss output fstatat() doesn't report "No such file or directory" for /etc/TZ and /etc/timezone it's because I tried stop this behaviour creating those file as symlinks that point to the same timezone that /etc/localtime points to.
 

Attachments

plasmashell is spiking at 99% CPU usage ever since I upgraded to 6.6.2 (FreeBSD 15). Anybody hitting the same?

I'm experiencing the same. But not only plasmashell, sddm too: according to truss output both seems to be in a loop executing fstatat() on four files (happens with both Xorg and Wayland session):
  • /etc/TZ
  • /etc/localtime
  • /etc/timezone
  • /var/db/zoneinfo
After a while sddm stops this loop, but plasmashell doesn't. I'm attaching the file with the output for plasmashell, just in case this could be useful to someone.

P.S. If in truss output fstatat() doesn't report "No such file or directory" for /etc/TZ and /etc/timezone it's because I tried stop this behaviour creating those file as symlinks that point to the same timezone that /etc/localtime points to.
Ok, just solved it! :)
As FreshPorts' page for plasma6-plasma-workspace reports for version 6.6.0, there is a bug (PR 293368) that causes this loop. The workaround is to set the Clock widget to never show seconds.
More infos on the commit: https://cgit.freebsd.org/ports/commit/?id=a9f8378e37f45046ee91f0f9ad660d8fb2b77663.
 
How to configure SDDM to start this session?
This
Code:
Exec=/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-wayland
does not work.
The sequence is incorrect here... the /usr/local/bin/ck-launch-session comes first, and then the /usr/local/lib/libexec/plasma-dbus-run-session-if-needed... At least that was the case last time I tried to run Plasma Wayland from command-line. You also gotta have the following folder: /usr/local/share/wayland-sessions, readable by SDDM.
 
You also gotta have the following folder: /usr/local/share/wayland-sessions, readable by SDDM.

I have this folder and one file in it with that same exact sequence, but it is not seen by SDDM at all. If I copy that file to /usr/local/share/xsessions, it is seen, but does not work.
 
Update: Plasma 6.6.2 is now in official Ports Collection. I compiled my way into a usable KDE desktop. And:

1. SDDM and lockscreen work fine. The trick is to never let the system sleep, be it on battery/low battery or ac power. That's because the sleep function doesn't work properly on FreeBSD. Sleep has been a problem under Xorg, as well, so I know it's NOT Wayland-related. You can turn off sleep by going to KDE's System Settings app -> Power Management.
2. Konqueror still crashes under a Wayland session. This is a paper cut, not a showstopper. If someone has the time to generate a patch with ChatGPT or Claude Code, that would be nice. I can post the error messages (which are only visible if Konqueror is launched from command-line, like Konsole) a bit later. Point here being, Konqueror will spit out error messages (indicating that it was not ported to Wayland properly), and dump core into $HOME directory.
3. Yeah, KDE is a RAM hog, but even then, I don't think it should show that all 40 GB of RAM on my laptop is full. Especially when considering that the laptop is actually surprisingly responsive. The top(1) output shows that 18GB of my RAM are actually free. That means that KDE's System Monitor applet is not displaying correct info for me. And this is a papercut, not a showstopper.

Overall, my take is, Plasma Wayland on FreeBSD is progressing very nicely, and will be in good shape by the time KDE makes Plasma a Wayland-only thing for Plasma 6.7/6.8...
😁
 
3. Yeah, KDE is a RAM hog, but even then, I don't think it should show that all 40 GB of RAM on my laptop is full. Especially when considering that the laptop is actually surprisingly responsive. The top(1) output shows that 18GB of my RAM are actually free. That means that KDE's System Monitor applet is not displaying correct info for me. And this is a papercut, not a showstopper.
I had this problem too, I solved it thank to AlfredoLlaquet who wrote a how-to:
How to Get RAM and Swap Usage Widgets to Work on Plasma
The only difference is that I choose to show the amount in digits instead of the percentage. Works beautilfully. :)
Overall, my take is, Plasma Wayland on FreeBSD is progressing very nicely, and will be in good shape by the time KDE makes Plasma a Wayland-only thing for Plasma 6.7/6.8...
I agree. I was reclutant to try the Wayland session, but had to say that things are going pretty well.

Even sysutils/plasma6-kinfocenter has been patched to don't depend on Linux programs: Network interfaces info are shown, and sysutils/fwupd and vermaden's sysutils/sensors are used to show firmware security and sensors info respectively. :)
 
Well, wow. Now that most papercuts have been mostly taken care of, there's a huge and really frustrating showstopper: Interacting with the amdgpu driver!

This is relevant to KDE Wayland, because that's the combination that seems to trigger the bug in the amdgpu driver - the PSR (Panel Self Refresh) bug.

This bug has at least 3 open tickets on gitlab.freedesktop.org:
The bugs are Linux-related, but as a reminder, FreeBSD's graphics/drm-kmod gets its drivers from Linux. And it looks like I've been hit by that showstopper bug.

Reading up on the bug, it seems to be related to race conditions present in how the amdgpu firmware drivers operate.

There is a patch mentioned that supposedly helps (https://lists.freedesktop.org/archives/amd-gfx/2026-February/138842.html). Not sure how long before it makes its way to FreeBSD...

Also, a Phoronix commenter mentioned a couple ENV variables that helped him on Linux:
Code:
KWIN_DRM_NO_AMS=1
KWIN_DRM_NO_DIRECT_SCANOUT=1

Gotta do some research to figure out how to use those ENV variables in FreeBSD, and figure out if they help me or not.

Man, if this doesn't help, I may end up needing Intel hardware.
 
Gotta do some research to figure out how to use those ENV variables in FreeBSD, and figure out if they help me or not.
Setting them in your .profile should work, since various shells configuration files are sourced at login, but if you want something more "plasma-specific" create a file with .sh extension in $HOME/.config/plasma-workspace/env and export those variables there.
I use a file named env.sh to make GTK programs use KDE file picker instead of the GTK one this way:
Bash:
export GTK_USE_PORTAL=1
I also made it executable, but I don't know if it is needed.
 
Back
Top