KDE Plasma Wayland on FreeBSD
When I wrote about Wayland on FreeBSD I did not expect it to trigger “remove Wayland” kinds of comments in FreeBSD ports. Rather than spend time patching ports to remove functionality that we actuallyt want to work in future, I sat down for most of a day to wrestle with KDE Plasma Wayland on an Intel-based laptop (a Slimbook Base 14, still a lovely machine even if I have not gotten full FreeBSD support on it yet).
The real work of “try this”, “try that”, “set this debugging environment variable” was done by Vlad Zahorodnii. Thanks Vlad, for responding to all my “it still doesn’t work” with patience. David Redondo pushed things in the right direction, too.
Source Level Changes
Remember the system-call
mknod()? And in the ’90s where you
had device major and minor numbers assigned to specific bits of hardware?
If you don’t, that’s fine, it wasn’t good. But the macro’s
minor() still exist to handle device numbers which are encoded in
a single int, but conceptually are separate numbers.
Spot the difference in the manpages for
Passing raw return values from the macro’s to DBus yields type mismatches: integer versus unsigned. Once we fixed that KWin (being the Wayland compositor for KDE Plasma) would at least start.
FreeBSD i386 has a 32-bit
time_t and in spite of it being very unlikely
someone would use that as a FreeBSD desktop system with Wayland,
the code needed a small get-it-to-compile patch there.
Finally I added a “things are not going to work out” timer that stops KWin in such a case. This helps guard against various kinds of broken systems or incomplete installations: you’ll get your screen and keyboard back after 20 seconds.
These code-level changes are all in KDE Invent although I’m not sure they’ll land in this form – or in that branch. More likely they will be massaged and landed in the development branch, to be integrated with some future release. There are still things to iron out, and for now, doing that in packaging is the easiest.
System Level Changes
The KDE Plasma Wayland code is still a bit Linuxy and contains some assumptions – simply because we’ve not chased cross-platform compatibility issues yet.
On Linux, you can enumerate DRM-enabled devices, it seems via udev.
The FreeBSD shim that behaves like udev doesn’t really like that.
The one-and-only DRI interface is at
That’s what the (Linux-compatible)
i915kms module gets you.
nVidia users are SOL, at least until I feel like ending my X11
session on my workstation and building a patched KWin again.
Another assumption is that
/proc exists and follows the Linux layout. Nope.
Things seem to work without it, although there’s plenty of failed to identify
One the thing to do is to “give in” and mount
the Linux-compatibility-layer in the expected spot. This
may conflict with Steam-compatibility on FreeBSD, so you
may have to choose gaming or Wayland.
mount -t linprocfs linprocfs /proc
/proc filesystem is used to get the name-of-the-executable for a given PID; I’m
sure FreeBSD has an API for that somewhere that we can use instead.
/proc, right now, the Wayland compositor doesn’t know what executable
is talking to it, and so can’t decide on privileges. This is most easily seen
with Spectacle: it can’t take screenshots otherwise.
There were some missing dependencies which is why KWin from FreeBSD ports didn’t support “all the things”. Adding in frameworks dependencies like kwayland-integration improved that situation, but regular users will need to wait for the package-building-cluster to get through that (expect May first 2021 or so).
I added yet-another-startup-script to actually launch KDE Plasma Wayland,
so I wouldn’t have to write extensive instructions here.
Running KDE Plasma Wayland
You will need:
- FreeBSD 13 or later. I’m not going to look at 12-or-older compatibility.
- Intel i915kms graphics. I’m not going to look at AMD compatibility, or nVidia for the time being.
- No display manager.
service sddm stopwill do for now.
- The sufficiently-new packages for plasma-workspace and kwin installed.
To run it:
- Boot to a text console,
- Log in as a regular user,
The shell script sets up some things – described in my previous Wayland post –
and then uses ConsoleKit and DBus wrapper scripts to start
which does the real work – so this is a multi-stage rocket, launched by a multi-person
effort on multiple-OSses and machines, and it will get you this:
- Cursors are weird some of the cursors are fine, and some – the cursor over the background image, or the I-beam over konsole – show an all-glitched-out graphic. Instead of an I-beam, I get half of a “stop” symbol.
- Drop downs need some love. For instance, Konqueror’s history-drop-down in the URL bar just causes weird flickering. Falkon’s history drop-down does not, so I suspect it’s in application code to “do the right thing”. I had a KMail bug open for a long time about this – the message-composer would glitch-out everything when used – but that has been fixed: again, probably something that needs application-level tweaks.
- Rick Astley may not give you up, but getting out of a KDE Plasma Wayland session can be
tricky, too. After exiting, you may get lots and lots of crashes as applications in the
Wayland session die. Beware of stray Dr. Konqis. You may also need a
stty saneafterwards to get things back to normal. But on the whole, why would you exist a KDE Plasma Wayland session anyway?