X.Org on NetBSD - the state of things

A few years ago, I wrote a "state of things" blog post about Wayland on NetBSD. It's only natural that I should do one about X11, which is used by far more people to get a graphical environment on NetBSD.

There are a lot of differences from how NetBSD and the typical distributor ship X.Org. For one, we ship it as an optional monolithic package rather than separate individual packages. This means every driver is included on every system, rather than as an optional module. Sometimes, this means we need to fine-tune driver selection to ensure the correct drivers are loaded on the correct hardware, since multiple conflicting drivers can claim a video output. We also want sensible fallbacks, since if you're using a GPU from the future with an old OS version, you probably want X to seamlessly fall back to a regular framebuffer.

Secondly, the way our "xsrc" repository is set up, it's effectively functioning as a fork of X.Org that regularly pulls from upstream freedesktop.org (but does not push back). This allows X development to happen as part of NetBSD.

Thirdly, we use our own build system based purely on BSD makefiles, not X.Org's based on GNU autotools. This fits well with our build.sh cross-compilation system.

We have a number of drivers which have not made their way upstream. Perhaps the most ubiquitous of these is xf86-input-ws, a driver which came from OpenBSD, targets an API from NetBSD, and continues to be developed in both. This is a generic input driver that can support any pointing device that the kernel supports. Unlike xf86-input-mouse, it doesn't assume the device is a mouse, and can support advanced touchpad and touchscreen features. Other NetBSD exclusives include xf86-video-pnozz, xf86-video-mgx, and xf86-video-crime. While these all share the "xf86" name inherited from the historical XFree86 distribution, none of them are exclusively for x86.

There are a number of drivers that are accelerated when used in NetBSD, but the acceleration support is missing upstream. This is mostly due to the work of macallan@, who has diligently worked on drivers for accelerators found on SPARC and PowerPC hardware.

X.Org has historically supported two 2D acceleration modes, XAA and EXA. XAA seems complicated - according to the X.Org Foundation it supports accelerating "patterned fills and Bresenham lines" (eh?). XAA was removed from the X.Org server in 2012, and many old drivers were not updated to support the newer and simpler EXA model, except in NetBSD, over a time period of several years.

Did you know that Nvidia used to have an open source graphics driver? It supported 2D acceleration for a range of cards. In NetBSD, it's retained for platforms that included embedded Nvidia chips and aren't capable of (or predate, or don't want) the modern novueau driver. Six years ago, it was updated in NetBSD to support EXA acceleration.

There are a few ways our X integration could be improved. While lots of attention has been paid to the server, less has been paid to clients (programs). Did you know that X includes a text editor, and that text editor supports syntax highlighting and spell checking?

NetBSD includes its own command-line spell checker and associated dictionaries, spell(1), inherited from the BSD UNIX of yore. It's pretty basic, and only supports variations of English. To get spell checking to work in xedit, you need to install ispell (another command-line spell checker) from pkgsrc, install a dictionary, then set some Xresources (or create symlinks) to make sure xedit finds ispell. This could surely be streamlined by teaching xedit about spell.

We also ship every program that has been included with historical X.Org distributions. This includes well-known things like xterm, slightly less well-known things like xbiff(1), and obscurities like bitmap(1) (apparently a 1-bit-per-pixel alternative to MS Paint). A while ago, we removed some libraries which are no longer used by the modern X server, and maybe we should evaluate whether we need all of these programs too. xmh(1) is a frontend for a mail system that isn't included in base. Together, bitmap and xmh are around 300 kilobytes.

We include fonts, bitmaps and scalable, for a wide range of computing devices. In the latest versions of NetBSD, the font size will automatically scale with the screen size to support HiDPI displays as well as small mobile devices. However, we don't ship a scalable cursor theme at the moment. We're also missing high-resolution fonts for Japanese, a shame considering the popularity of NetBSD in Japan. Koruri looks interesting and is suitably small, maybe we should import it.

While we have many useful simple programs by default (a clock, a calculator, an editor, a window manager, a compositor, a terminal emulator...), we're notably missing a screen locking program for X in the default install, although we have lock(1) for the tty.

The big question - does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it's likely we'll run into things that will never be suitable for upstream.

Of course, on NetBSD, you also have the option of trying vanilla modular X.Org from pkgsrc, or using something else entirely.