Present to the future challenge

[bugcrazy]

Currently 5 display servers: Xorg; Xenocara; Arcan; Nano-X; Wayland, which can be used on Unix-like, Xorg is being deprecated, only a few devs and Oracle maintain it, Wayland invents the wheel and has a lot of design problems.

https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html

https://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html

https://www.reddit.com/r/linux/comments/wwsiaf/writing_a_wayland_compositor_is_much_harder_than/

swaywm/wlroots#1826

Nano-X has a lot of potential, but it lacks a port for *BSDs and new releases, which makes adoption difficult in distro repositories.

[markusbkk]

Small correction:

Wayland isn't a display server. Wayland is a set of protocols and an infrastructure for building display servers. That's why there's a massive amount of code involved writing a Wayland compositor (a Wayland compositor is essentially a display server and a window manager wrapped into one) and why not all frameworks in the vein of wlroots (Louvre, runa, Smithay and the half a dozen wlroots bindings to other programming languages) are equal.

The creator of Arcan often seems to consciously avoid the term "display server" and has explained this choice multiple times in the past.

Arcan is presented as a ‘desktop engine’ and not as a ‘display server’ for good reason. In this context it means to consolidate all the computing bits and computer pieces useful when mapping our perception and interaction into an authoritative behaviour and permission model, one entirely controlled by user provided scripts.

The ‘engine’ here is covered by the main arcan binary and invites parallels to app frameworks in the node.js/electron sense, as well as the ‘Zygote’ of Android.
It fills two roles — one is to act as the outer ‘display server’ which performs the last composition and binds with the host OS. The scripts that run within this role is roughly comparable to a ‘window manager’, but with much stronger controls as it acts as ‘firewall/filter/deep inspection’ for all your interactions and data.

BTW: There's even more display stacks around than the ones you mentioned.

• Canonical's Mir is still around, even though it's more or less a Wayland compositor with its own API now. It does make working with Wayland way easier though.
• Android uses Surface Flinger.
• Something like Plan9's devdraw could potentially also be used in conjunction with other display technologies, to create something akin to a more modern and smaller X11 replacement.

EDIT: I almost forgot about the venerable DirectFB, which has seen somewhat of a revival in its latest DirectFB2 incarnation and is widely used by LG to provide the UI for its WebOS based TVs.

[markusbkk]

My personal opinion on the matter is that the future belongs to a layered display stack.

You don't really need to decide between one display server or the other. Most of those technologies support nesting one in the other.

Arcan is capable of running X11 and Wayland clients inside of its display.
Likewise, Arcan is also capable of running as a client inside X11.

Wayland compositors aren't limited to being the main display server either.
There's at least one Wayland compositor (Greenfield) that displays its clients inside a browser window, making the browser itself (which can run on X11, Arcan, Wayland or any number of other technologies) a sort of "middle layer" display server.
Furthermore, just like Arcan, Wayland can run nested inside of X11.

X11 exists in multiple incarnations including Xarcan, Xwayland, Xephyr (itself based on KDrive), Xquartz and Xpra.
It's incorrect to claim that X11 is being fully deprecated. Only the X.Org server implementation is but there are many others and it too allows a layered approach since X11 clients can run inside Wayland, Arcan, Microwindows and even the browser (through Xpra or Microwindows).

Finally, Microwindows has a number of screen drivers (namely, it can run inside a Memory-mapped framebuffer, on top of X11, inside an SDL 2 or Allegro 5 window, on top of Windows and inside an X11 based framebuffer emulator) so I see the main value of it in its abstraction not necessarily having it run as the main display server on top of a framebuffer.

Google ChromeOS is a good example of the benefits of a layered display design.
I doubt many people even noticed that its Aura Shell kept switching display servers. For the first 3 years of its conception, ChromeOS Aura shell windows were running on top of a display-filling, frame-less X11 window. After that Google switched to its own Freon stack which was a fairly simple DRM/framebuffer implementation. In 2020 they then made the switch to their own Wayland compositor. None of this migration was visible to the average user. It was all seamless and none of the 3rd party developer facing APIs had to change either.

If I were going to create a Microwindows reference distro (it's enticing, to say the least. If there was a GTK3+ driver, I probably would have used it for my current OS design already), I'd choose the SDL backend and use either Arcan or the simplest possible Wayland compositor implementation to display Microwindows' root window full screen/frame-less.

I'm currently test-driving EltaninOS/Glacies (Download) and boy has it been a pleasure thus far.
It uses the Linux kernel but has its own userland and eschews X11/a Wayland compositor for Arcan. Something similar could be done for Microwindows quite handily.