The Wayland trojan horse
Homepage->Blog index
The Wayland trojan horse
Date written: 2025/06/16
Standardization of graphical environments has always had a rocky history. Not every vendor provided one in the 20th century on their machines, and those who did generally provided an entirely proprietary solution that was custom built for the given device. Some well known consumer grade examples of the time would include the Macintosh UI, the Amiga Workbench, and who could possibly forget Microsoft Windows. The Unix sphere was in a similar boat for a long time, with window systems like SunView, MGR, NeWS, NeXTStep and many others.
Certain graphical environments meant for use across different platforms did exist, like GEM, seeing adoption on platforms like the Atari ST (TOS) and IBM PC (DOS). This provided a level of application portability at the GUI library level, but it was still far from universal due to various architectural differences, as well as being developed exclusively for use in single user sessions local to the machine.
The Unix world would see a complete shakeup in the mid to late 80s with the public release of the X11 Window System, which was specifically designed for remote, multi-session use with a client-server model that is entirely architecture independent and is driven by a message queue system. Seeing as how remote operation of different types of Unix machines with multiple users at once was a very common use case at the time, it quickly saw wide adoption by most of the major Unix vendors.
X11 has a very simple job: be a family of protocols that provide a way for applications (clients) to create and position windows, draw primitives and bitmaps in those windows, and various other functions that allow a graphical environment to function. What it does NOT provide is a full desktop environment with a suite of applications, or even a window management system. These are all meant to be built on top of X11 and run in an X session provided by an X server. Vendors and independent programmers could develop their own application bundles that would simply run in an X session and interact with one another as needed, which we would see with simple window managers like TWM, VTWM, FVWM or similar, and even full-blown desktop environments like OpenWindows, IRIX Desktop, and others (modern day equivalents would be GNOME, Xfce, KDE, etc.).
There was somewhat of a standardization dilemma across the major Unix vendors in regards to application GUI design and development, which resulted in the birth of toolkits like Motif and desktop environments like CDE, which would ensure a common look and fell across entirely different Unix flavors. Even in cases where the remote system was of a different architecture and even different operating system family, you could still run applications as long as they were made to talk with X11. Want to run a GTK application from an x86 Solaris remote host within a local POWER10 AIX system's CDE session? You can do that! Have a dedicated X server application running on a Windows machine? It'll happily display the application too!
Times change, and so do common use cases for any given thing. Running graphical Unix applications remotely is now a niche, people for the most part run local sessions with various forms of GPU acceleration in multi-monitor setups with DPI scaling of UI elements on modern Linux or BSD operating systems... and yet, X11 is somehow still around. The fundamental principles of X11 operation remained the same, but many of it's surrounding layers had to change to accomodate modern use cases. Combine this with the age of the protocol and the legacy features that have to stay around, and maintenance becomes incredibly difficult. Multiple times in the 21st century have developers tried to draw a line in the sand and start anew, shedding what came before. You probably forgot many of these attempts ever even happened due to their failure to gain traction, but one has risen above the rest: Wayland.
In some ways, Wayland tries to be what X11 isn't. It doesn't provide a level of network transparency, as it's designed to be used locally first and foremost. In other ways it takes X11's principles to their extreme, as it's protocol is even more minimal. This changes the fundamental link between applications and the environment, as now applications must run under a window compositor to be properly displayed. It is not enough to simply have a display server, because the server does not perform compositing. The burden now falls on the graphical environment itself.
This doesn't sound too bad at a surface level, but you must realize that Wayland itself is not a standalone system. You don't run a compositor on top of a Wayland host session, the compositor is the Wayland session. "What's the big deal?", you might wonder, "I just have to run a compositor like I would a window manager or desktop environment, and applications developed for Wayland should just work.". This...