Item — HN Reader

> Was Wayland not architected to fix latency issues?

It was designed to fix tearing issues, not latency issues.

But then the Wayland designers found out that players often prefer tearing to minimize latency, so the tearing protocol was implemented.

When a committee of perfectionists, rather than real people or companies, design something, you often get something that is completely unusable by anyone but that committee.

And that's exactly how it's played out so far. Wayland is still largely incomplete, not to mention it doesn't even have a reference implementation [1], and still doesn't include/describe several essential desktop APIs and features, which results in this protocol not having a ton of universal tools and applications that work across all of its implementations, including but not limited to:

    * Keyboard layout switching and input management
    * Display configuration
    * Clipboard management
    * Tools to manage windows/automate tasks
    * Lots more

It's a damn ugly mess that has led to a lot of fragmentation with no obvious benefit. Currently, only KDE and Gnome have somewhat usable Wayland implementations. If you use anything else? You're SoL.

1. https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

5 comments

It's almost like you don't want tearing when browsing the web and your documents, but games can take over the precise control of rendering.. because they are games that want to do so?

How is that bad design?

The numbers presented in the article (~1 additional frame of latency on Wayland) are from someone using GNOME with the Mutter compositor. This means that neither the X11 or Wayland session has screen tearing. I imagine the X11 input latency numbers would go down by around half a frame on average if the author was using a different window manager without a compositor.

Of the things you list, IMO, maybe the display configuration should be part of the Wayland protocol.

It might be a better technical design to have the other stuff outside of the display protocol. Just because Xorg implemented something does not mean you have to put it in the Wayland protocol.

Routing of input events to windows has turned out to also be extremely important for a display subsystem in practice. It wasn’t just X11 that did this, it was also the NeXT window server, and Sun’s NeWS, and SGI’s pre-X window system, and the original VAXstation window system on VMS, as well as how both modern macOS and modern iOS and iOS-derived platforms work.

In any of these cases there may be one or more daemons behind the scenes handling the “raw” input—possibly even in cooperation with kernel-level pre-processing code, to ensure low latencey—but most event delivery to applications is associated with windows, with options to get lower-level access if needed.

One of the things that helps many of the systems described above with latency is kernel participation, whether by pushing much of the preprocessing of events down to the drivers so there’s little for userspace to do, or by implementing kernel-level zero-copy IPC (e.g. use of Mach messages by NeXT and Apple).

If human interface IPC happens entirely in userspace and requires multiple context switches to get an event from device to a display change, you’ll wind up with hitches and delays unless there’s some sort of scheduler hinting that ensures each stage in the pipeline runs immediately after the last.

This is, of course, why there was a lot of desire by Wayland advocates for kernel dbus support, but they went at the problem backwards: “Let’s take DBus, and make it fast by putting it in-kernel,” *without* first trying to make it as fast as possible without kernel support, *and* without trying to figure out the minimal feature set for kernel-level IPC that would be needed to support it (which may not look like DBus).

> It was designed to fix tearing issues, not latency issues.

Actually is was designed because the X11 codebase was bad and nobody wanted to work on it.

> Actually is was designed because the X11 codebase was bad and nobody wanted to work on it.

This sounds like "Wayland codebase is good and everybody wants to work on it".

As I understand it, the tearing thing (no vsync) was only implemented after Valve pleaded, begged, and sacrificed a small animal to the Wayland developers.

> Currently, only KDE and Gnome have somewhat usable Wayland implementations. If you use anything else? You're SoL.

Wlroots exists.

A library exists, correct.

Good luck using it as your graphics subsystem.