X.Org on NetBSD - the state of things

May 04, 2024 posted by Nia Alarie

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.

Spinning glxgears, a classic X.Org program.

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?

xedit, the standard editor

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.




I wonder why some of the more general NetBSD improvements haven't been incorporated upstream (say EXA support for some drivers, or the pointing device). Is it a manpower issue? A lack of interest on either side? Philosophical differences with the project? The expectation for them to come and take it rather than you pushing it upstream?

Posted by Mario on May 04, 2024 at 05:04 PM UTC #

Nevermind, I shouldn't comment on the internet before having my coffee. My brain completely skipped this: > The process of upstreaming stuff to X.Org is an ongoing process Like, the answer was already there, I did read it before posting, but never really understood what it meant. Anyway, glad to see there's an attempt to get those upstream, they seem like good additions to share among OSes :)

Posted by Mario on May 04, 2024 at 05:09 PM UTC #

Excellent write up! Hopefully it answers some questions those unfamiliar with NetBSD might have. I'm really happy with the integration with NetBSD's build system! It simplifies so much! I agree xmh is unnecessary as if I'm not mistaken it requires MH be installed as well. For screen locking an import of x11/slock might be an answer. I would disagree with removing anything else though.

Posted by Greg A. Woods on May 04, 2024 at 08:03 PM UTC #

I'd like to see an updated post about the current state of Wayland on *BSD as well. A *ton* has changed since 2020 in the Wayland world, with it new being the default across both Gnome and KDE (which combined, make by far the bulk majority of the Linux userbase), and I would be curious to see the state of this particular "shiny new squirrel" on the BSD side of thing ;)

Posted by QwertyChouskie on May 05, 2024 at 01:10 AM UTC #

meow meow

Posted by test on May 06, 2024 at 01:33 AM UTC #

I liked. Helps understand NetBSD. Thanks Nia!

Posted by genv on May 06, 2024 at 07:53 AM UTC #

"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." Please don't break backward compatibility.

Posted by Longtime NetBSD Users on May 06, 2024 at 09:26 AM UTC #

Thank you for this article about Xorg in NetBSD. It was an interesting read. — Adrian

Posted by Adrian Kieß on May 07, 2024 at 04:43 AM UTC #

> not X.Org's based on GNU autotools Huh? Autotools haven't been in the codebase for years, what are you talking about?

Posted by Constantine on May 09, 2024 at 04:05 PM UTC #

Thank you for this information it is very helpful for me nice. [url=https://www.hpinstantink-hp.com]HP Instant Ink Subscription[/url]

Posted by andrea924breaux on May 27, 2024 at 10:43 AM UTC #

Thank you for this information. <a href="https://www.hpinstantink-hp.com">hpinstantink</a>

Posted by andrea924breaux on May 27, 2024 at 10:44 AM UTC #

Since we're currently doing lots of cleanups and refactoring in Xorg - including old remains XAA in various drivers - could you please upstream your patches ? And also let's get into closer discussions (probably @xorg-devel) on the exact relation (and workflows) of your fork vs. upstream, e.g. how to you actually create/maintain your makefiles ?

Posted by enrico weigelt, metux it consult on June 10, 2024 at 03:10 PM UTC #

Post a Comment:
  • HTML Syntax: NOT allowed