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 major() and 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 makedev(3): FreeBSD and Linux.

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 /dev/dri/card0. 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 <pid> messages. 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

The /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. Without /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.

Packaging Changes

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. You’ll want plasma5-plasma-workspace-5.21.4_2 and plasma5-kwin-5.21.4_4 from packages.

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 stop will 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,
  • Run /usr/local/bin/startplasma-wayland.sh.

The shell script sets up some things – described in my previous Wayland post – and then uses ConsoleKit and DBus wrapper scripts to start startplasma-wayland 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:

Screenshot of KDE Plasma Wayland on FreeBSD -- Rick Astley in video window
Screenshot of KDE Plasma Wayland on FreeBSD -- Rick Astley in video window

Known Issues

  • 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 sane afterwards to get things back to normal. But on the whole, why would you exist a KDE Plasma Wayland session anyway?