Wayland on FreeBSD

One more in my series of “things on FreeBSD”, but this road does lead to things-KDE: KDE Plasma Wayland on a FreeBSD desktop. On my Slimbook, in fact. Many thanks to angry_vincent on IRC for showing some bits and pieces to me, and to David Faure for moaning about failing unit tests (which is what made me decide to figure out this Wayland stuff for once and for all).

My main desktop runs KDE Plasma on it. On FreeBSD, with X11, with an nVidia card (a fanless 730 – with great graphics power comes nothing useful) and the proprietary nVidia drivers. Works great, has for years. Since so many of the Wayland documents (e.g. the sway wiki say to piss off if you use nVidia), I did my testing on my laptop instead, which has an Intel iGPU.

I have a Slimbook and since I wrote about it 11 months ago FreeBSD hardware support has progressed a great deal. But that’s a topic for another time.

Pre-Wayland Work

I have built FreeBSD 13-STABLE and installed it on the laptop. To drive graphics, drm-kmod is needed; in my case that is a metapackage that pulls in drm-fbsd13-kmod. After installing it, load the module:

# pkg install drm-fbsd13-kmod
# kldload i915ksm

I get a nice shiny KMS system console: still text, but with a framebuffer.

The FreeBSD bootloader now does fancy graphics on start as well, in EFI mode: I’ll miss the blocky ASCII-art Beastie a little though. Props to @tsoome to building that (and far earlier, to @FreeBSDFrau, for easter eggs in the loader and other historical fancies). ASCII-art is still the default with a BIOS boot, and there are loader knobs to do one or the other (and it’s not like you need to reboot a FreeBSD machine regularly anyway).

Sway

Sway is easy to install: it’s in ports as x11-wm/sway (because there is no ports category “Wayland Compositors”). I’m not 100% sure about all the dependencies, so I explicitly installed seatd as well. Start the seatd service (just this once, for testing).

# pkg install seatd sway
# service seatd onestart

Sway and Wayland Versions

Note that sway builds against -devel versions of things, while other Wayland-based tools may build against the regular versions – this can lead to weird package install conflicts. There are -devel and plain versions of Wayland and XWayland in ports, and at this point in time with Wayland in some state of flux and rapid development, that makes some sense. At some point when Wayland becomes more mainstream I think we’ll be able to settle down with only experimental things using the -devel ports.

Not a week goes by that I don’t see some KDE work being done on the Wayland protocols and other upstream bits: the state of flux is real, as is KDE Plasma’s use of cutting-edge Wayland.

Sway Configuration

Sway needs (that is, it can run with) a minimal ~/.config/sway/config file:

input * xkb_rules evdev

It actually needs much more than this – read the manpage – but this will get you a mouse pointer that moves.

There’s some environment setup to do as well, for the user who will be running sway: an XDG runtime directory. Normally a display manager will take care of this, but right now with only a text console, more setup is needed:

$ export XDG_RUNTIME_DIR=/tmp/`id -u`-runtime-dir
$ test -d "$XDG_RUNTIME_DIR" || \
  { mkdir "$XDG_RUNTIME_DIR" ; chmod 700 "$XDG_RUNTIME_DIR" ; }

At this point, it may be possible to run sway as a regular user and get a grey-ish screen and a mouse pointer. Switch virtual consoles and use pkill sway to get rid of it, because as-configured (“minimal”) you get to see nothing and can’t exit, either.

Sway Actually Useful

I’m clearly not in i3’s target audience: I expect things full-featured and ready-to-go. Heck, even twm reacts to a mouse press by default. To make things happen with sway, install a terminal and a menu:

# pkg install alacritty dmenu dmenu-wayland

Extend the configuration to have a top-bar, to run a terminal, etc. This is all documented (in a read the example config, dummy kind of way) and the example file is quite readable. Here’s a cut-down want-to-see-something form:

set $mod Mod4

set $left h
set $down j
set $up k
set $right l

set $term alacritty
set $menu dmenu_path | dmenu | xargs swaymsg exec --

output * bg /usr/local/share/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill

input * xkb_rules evdev

bindsym $mod+Return exec $term
bindsym $mod+Shift+q kill
bindsym $mod+d exec $menu

bar {
    position top
    status_command while date +'%Y-%m-%d %l:%M:%S %p'; do sleep 1; done
    colors {
        statusline #ffffff
        background #323232
        inactive_workspace #32323200 #32323200 #5c5c5c
    }
}

include /usr/local/etc/sway/config.d/*

With this configuration, sway comes up looking more like a desktop, and you can start a terminal, too! For some folks (me, too, on some days), that’s all you need.

Sway with wallpaper - this needs more configuration than shown

Sway Optional

There are a handful of environment variables you can set. For older CPUs, angry_vincent tells me that this may be needed:

$ export LIBVA_DRIVER_NAME=i965

but my Slimbook with 10th-gen Intel CPU got along fine without.

To get applications to use Wayland by default, you may need to tell them so:

$ export MOZ_ENABLE_WAYLAND=1
$ export GDK_BACKEND=wayland
$ export QT_QPA_PLATFORM=wayland-egl
$ export QT_WAYLAND_DISABLE_WINDOWDECORATION=1

It may be useful – while messing around from the text console at least – to put all these settings (and XDG_RUNTIME_DIR as well) into a file that can be sourced by the shell.

To make settings persistent across reboots, always load the kernel module and enable seatd in general:

# sysrc kld_list+=i915kms
# sysrc seatd_enable=YES

Sway with Qt and KDE Applications

One of the dependencies of sway in FreeBSD is .. xwayland-devel, which seems a bit derpy to me (as in, why would you want non-native Wayland at all?). Nonetheless, this is necessary for some Qt / KDE applications to run, even with the QPA set to Wayland. I’m not sure why. Here are some Qt-based applications (some KDE applications) that I tried briefly in sway:

telegram-desktop
konsole
designer (this is not something you want to be running as the third window on a screen, it gets all scrunched up: but that’s i3 style)

I took a hammer and bashed the XWayland executable with it, to see if things could work without. Running konsole and designer with the /usr/local/bin/Xwayland executable removed was not successful; Telegram was ok.

River

With one Wayland compositor working, the next one, river should be a piece of cake: I know the hardware works, DRM and input handling is ok. I copied the sample river/init file .. take care to make it executable! The example uses foot as terminal, so I installed that as well:

# pkg install foot

After a few false starts (not-executable init, no installed foot, realising that slimbook-enter is Mod4-enter and that that was the keybinding in sway for a terminal, in the example river config it is slimbook-shift-enter), there is yet-another-i3-ish thing.

I don’t have much to say about river: it works. At best I can shout in exasperation: what is it about tiling window managers and Wayland.

KDE Plasma

This is the stuff I actually want to have for Wayland. I generally install the “fat” package from ports, kde5 (which includes KDE Frameworks, KDE Plasma and KDE Applications / Release Service / soon-to-be-Gear). There was a conflict with xwayland-devel since the KDE bits built (like, up until today) against slightly-older Wayland. I updated the x11-wm/plasma5-kwin port to use the -devel version too, which is what we ought to have as long as things are still being hashed out.

Last week I had patched this locally to let all of the wayland-based beasts co-exist.

Unfortunately, KDE Plasma Wayland just sits there. KWin never comes up properly, either when started from SDDM or from a text console. Some messing around shows me that setting up libinput bindings is failing, and at that point I got distracted by other stuff that needed doing, so ..

Call it a work in progress. On FreeBSD moreso than on Linux, where Aleix can spend a whole year in (and on) Wayland.