Wayland on NetBSD - trials and tribulations


September 28, 2020 posted by Nia Alarie

After I posted about the new default window manager in NetBSD I got a few questions, including "when is NetBSD switching from X11 to Wayland?", Wayland being X11's "new" rival. In this blog post, hopefully I can explain why we aren't yet!

Last year (and early this year) I was responsible for porting the first working Wayland compositor to NetBSD - swc. I chose it because it looked small and hackable. You can try it out by installing the velox window manager from pkgsrc.

A Wayland compositor running on my NetBSD laptop, with a few applications like Luakit and Dungeon Crawl Stone Soup open.

Difficulties

In a Wayland system, the "compositor" (display server) is responsible for managing displays, input, and window management. Generally, this means a lot of OS-specific code is contained there.

Wayland does not define protocols for features X11 users expect, like screenshots, screen locking, or window management. Either you implement these inside the compositor (lots of work that has to be redone), or you define your own protocol extension.

The Wayland "reference implementation" is a small set of libraries that can be used to build a compositor or a client application. These libraries currently have hard dependencies on Linux kernel APIs like epoll. In pkgsrc we've patched the libraries to add kqueue(2) support, but the patches haven't been accepted upstream. Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs.

So far, all Wayland compositors but swc have a hard dependency on libinput, which only supports Linux's input API (also cloned in FreeBSD). In NetBSD we have an entirely different input API - wscons(4). wscons is actually fairly simple to write code for, someone just needs to go out there and do it. You can use my code in swc as a reference. :)

In general, Wayland is moving away from the modularity, portability, and standardization of the X server.

Is it ready for production?

No, but you can play with it.

  • swc has some remaining bugs and instability.
  • swc is incompatible with key applications like Firefox, but others like Luakit work, as do most things that use Qt5, GTK3, or SDL2. Not being able to run X11 applications currently is quite limiting.
  • Other popular compositors are not yet available. Alternatively, someone could write some new ones.
  • You need a supported GPU or SoC with kernel modesetting, since safe software fallbacks don't work here. So far, I've only tested this with Intel GPUs.

Task list

  • Adding support for wscons to more Wayland compositors and persuading developers to accept the patches.
  • Persuading developers not to add hard dependencies on epoll and instead use an abstraction layer like libevent.
  • Updating the NetBSD kernel DRM/KMS stack. This is a difficult undertaking that involves porting code from the Linux kernel (a very fast moving target).
    • Getting support for newer DRM versions
    • Getting support for atomic modesetting
    • Getting support for Glamor X servers (for running X11 applications inside wayland, etc)
    • Newer AMDGPU drivers, etc
  • Adding support for basic (non-DRMKMS) framebuffers to a Wayland compositor. X11 can run from a basic unaccelerated NetBSD framebuffer, but this isn't yet possible in any Wayland compositor.
  • Extending swc to add more features and fix bugs.

I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option.

[6 comments]

 



Comments:

Really great! A small change like this can make a big difference to new users.

Posted by Dan on September 28, 2020 at 06:10 PM UTC #

Nice summary of the state of things on Wayland, thanks. Is my impression, though that even on Linux, the large majority of users is still running Xorg.

Posted by pin on September 29, 2020 at 04:14 AM UTC #

I'd tackle wlroots after swc, since it seems to be the most widely used base library for Wayland compositors (that aren't rolling their own).

Posted by bb010g on September 29, 2020 at 06:11 AM UTC #

The problem with legacy APIs like wscons (other than nobody wanting to accept patches to support them) is that they're restrictive and prescriptive, as in “this is a mouse, it has X/Y and scroll and buttons”. Evdev is open-ended, kinda like passing HID events through to userspace with slight simplification/normalization. Which lets userspace support all the awesome new kinds of input. *Years* of effort went into libinput's support for touchpads&tablets. Resistance is futile. Adopt evdev in your kernel :P In FreeBSD, we support full multi-touch on touchpads and touchscreens via USB and I2C, pen tablets, gamepads.. without patching. And we can use the rich tooling ecosystem around evdev — network forwarding, record-and-replay, etc. (Also feel free to use our battle-tested libepoll-shim library instead of patching everything!)

Posted by myfreeweb on September 29, 2020 at 12:16 PM UTC #

libinput sucks. I have a Linux laptop and had to install synaptics to get my trackpad working. Apparently, libinput couldn't handle it :)

Posted by pin on September 29, 2020 at 03:20 PM UTC #

Maybe you better try Arcan (https://arcan-fe.com/), it already officially supports Linux, FreeBSD and OpenBSD, and uses their respective native input systems (evdev, syscons and wscons), so porting it should be trivial and of course you can run both X11 and Wayland clients in it with Xarcan and Waybridge (Xwayland support included), also its window managers are written in Lua while Arcan itself is written in C

Posted by leo on October 13, 2020 at 08:13 PM UTC #

Post a Comment:
  • HTML Syntax: NOT allowed