I, as a person who tries to use cutting edge technology, am a Wayland user, and ever since I started using it, I haven’t been able to get the thoughts about its problems out of my head. It’s time to get this thing off my chest. Here are the reasons Wayland is still not here:
The main problem
You may think that it’s the fact that it was decided to move from the “there’s only 1 display server” idea. You’re wrong, as that would invalidate the core goals of the project - to be just a protocol that requires implementations.
What can’t be denied, however, is the fact that instead of creating a full-featured “batteries included” set of protocols and a reference implementation of a library, compositors based on which could compete with X by being just as feature complete, there was created only a simple compositor, which can only satisfy the needs of a kiosk and not a modern desktop environment. An unofficial version of such a library didn’t even appear until 2017.
The consequences it has
Feature incompleteness
After 12 years of development, the implementations of the protocol still have a series of features incompletely implemented:
- Color management - 1, 2, 3, 4
- Variable refresh rate support -
1,
2,
3 - DRM leasing - 1, 2
- Input simulation and window control - 1, 2
- High bit depth display support
- Remote desktop
- Screencasting
- Client-side global hotkey binding
- Nvidia GPU support - yes it is indeed Nvidia’s fault, but to the end user it makes no difference
As you can see, it’s not so many, and the partial fault here is on clients rather than servers.
Implementation difficulty
On the server side, while it’s true that Wayland makes implementing a display server much easier, implementing a window manager is still a nightmare. For example, even using a library, you need to write a thousand lines of code to implement the absolute bare bones compositor, which won’t even support such critical things as damage tracking, hi-DPI, graphical tablets, multiseat, and any input/output configuration. X, on the other hand, allows you to write as few as 50 lines of code because it handles most of things such as the ones listed itself.
Lack of standardization
Wayland’s core set of protocols while covering a wide range things, doesn’t provide ones needed to build a modern desktop environment such as a desktop shell protocol (to build such things as panels and launchers), a protocol to simulate input and control windows, a protocol to control the clipboard, and others, leaving that to the compositors. While such a set of protocols does exist, it’s not adopted by the majority of the compositors. A similar problem is happening to the set of protocols required to screenshot, screencast and remote desktop - the adoption by clients is extremely low. This makes working with Wayland and debugging it much less flexible and compositor-dependable than X, and makes developing clients even harder.
Lack of configurability
In contrast to X.org, which has a unified config system, each Wayland compositor has to implement configuration separately. This results in not only inconvenience when trying to move the config from one compositor to another or describing how to configure something, but also different feature coverage by different compositors. For example, a compositor may not implement an input configuration such as scrolling speed or graphical tablet mapping or an output configuration such as display bit depth. In some cases the compositor may not even implement any input configuration, which makes using it extremely problematic, especially considering such a problem doesn’t exist when using X.
Conclusion
Considering the listed problems, the Wayland’s future doesn’t look that bright. But don’t give up hope just yet, as long as we have projects like wlroots pushing the innovation, not everything is lost!