Friday, May 8, 2020

Wayland doesn't support $BLAH

Gather round children, it's analogy time! First, some definitions:

  • Wayland is a protocol to define the communication between a display server (the "compositor") and a client, i.e. an application though the actual communication is usually done by a toolkit like GTK or Qt.
  • A Wayland Compositor is an implementation of a display server that (usually but not necessary) handles things like displaying stuff on screen and handling your input devices, among many other things. Common examples for Wayland Compositors are GNOME's mutter, KDE's KWin, weston, sway, etc.[1]

And now for the definitions we need for our analogy:

  • HTTP is a protocol to define the communication between a web server and a client (usually called the "browser")
  • A Web Browser is an implementation that (sometimes but not usually) handles things like displaying web sites correctly, among many other things. Common examples for Web Browsers are Firefox, Chrome, Edge, Safari, etc. [2]

And now for the analogy:

The following complaints are technically correct but otherwise rather pointless to make:

  • HTTP doesn't support CSS
  • HTTP doesn't support adblocking
  • HTTP doesn't render this or that website correctly
And much in the same style, the following complaints are technically correct but otherwise rather pointless to make:
  • Wayland doesn't support keyboard shortcuts
  • Wayland doesn't support screen sharing
  • Wayland doesn't render this or that application correctly
In most cases you may encounter (online or on your setup), saying "Wayland doesn't support $BLAH" is like saying "HTTP doesn't support $BLAH". The problem isn't in with Wayland itself, it's a missing piece or bug in the compositor you're using.

Likewise, saying "I don't like Wayland" is like saying "I don't like HTTP".The vast majority of users will have negative feelings towards the browser, not the transport protocol.

[1] Because they're implementations of a display server they can speak multiple protocols and some compositors can also be X11 window managers, much in the same way as you can switch between English and your native language(s).
[2] Because they're implementations of a web browser they can speak multiple protocols and some browsers can also be FTP file managers, much in the same way as... you get the point


asn said...

Wayland doesn't support color management!

Brad Laue said...

While creating a modern implementation is laudable, your web browser analogy aptly if accidentally illustrates the problem with the Wayland model: it's a specification left to others to implement, and like web browsers these implementations will NOT standardize.

The one strength of X11 is that its implementation came from a single project with distinct goals, and the results were reliable and feature complete from an end user perspective.

Ronan said...

My "Wayland doesn't support $BLAH" pet peeves (which still to this day cause me to stay on Xorg) are:

- Wayland doesn't support programmatic windows manipulation (to have an equivalent to X's wmctrl / xdotool).
- Wayland doesn't support keystrokes insertion (to have text expansion like provided on X with AutoKey, or macOS with TextExpander)

At that point, and given decades of existing X usage, I think it's disingenuous to refute the two cases by saying "it's not in the protocol, it's your compositor's job". It's a very designer-centric / user-averse way to put a functional regression!

To me it's more a sign that these features were missed by the folks who defined the protocol. I could manipulate windows with a command-line tool (wmctrl) working across all X desktops, and now with Wayland I cannot. I have to hope for (or write myself) something at the compositor level. This is a feature regression.

To echo Brad's comment and to utter one more semantically-debatable sentence: "Wayland is not as feature complete as X". I can do work under X that I cannot do under Wayland. Wayland disowns responsibilities that X had acknowledged, causing loss of functionality and the need to re-implement stuff for each compositor, which sucks for portability. My little marathon script to run or focus apps on X is a no-go on Wayland. To move to Wayland, I should A. wait for a protocol extension, or B. implement a Gnome Shell extension, then code in Sway when I move to Sway. That sucks.

Then there's security. Well, it would make sense then for these sensitive features to be off by default, and needing explicit configuration to enable them. Give me a comment/warning saying "Enabling programmatic window management by third party apps can be used by malware", then I can reflect on my security model and ponder if the benefits are worth the costs.

To my understanding, protocol additions are a thing. I hope these pet peeves get recognized at some point.

Do you see some validity to these arguments? If so, can you / should I bring them to a mailing list? Thanks for the discussion.

Peter Hutterer said...

Brad: go back in history and you find that there were plenty of different X servers with different extensions and you weren't guaranteed that a program worked unless you only used the core protocol. The only reason why X is a standard model is because everyone gave up maintaining a separate X server. Maybe in 10y time everyone uses mutter, in which case we're in the same situation as we are now with X.

Ronan: wcmtrl works through the EMWH/NetWM hints. You set a property on a root window and *hope* that the window manager understands and honours what you want to do. It's as much part of X as read() and write() are part of the JSON. It's a side-channel that all the window managers agreed on. So... exactly what you think is terrible in Wayland.

We're aware of some features regressing. Some of it is fixable, some isn't. Help is always needed, the number of people working on all this is... limited.

Luya Tshimbalanga said...

Both GNOME and KDE have their own color managements without depending on X server.
Also read this link to understand about the implementation of color managemetn for Wayland protocol:

Ronan said...

Peter: thanks for the response, the note about limited resources, and the technical correction, I didn't know wcmtrl works through the EMWH/NetWM hints, I assumed it was using X APIs.

Then, in a Wayland world, where should the features I'm ranting about (window manipulation by non-WM applications, text expansion) live, in your opinion?

- Is there room in the Wayland protocol to define them? If yes, in the core? Or in some sort of protocol "optional extensions" / "appendix"? Is there such a thing in Wayland?

- Or should there be a EMWH/NetWM equivalent for Wayland, specifying a side-channel that window managers may choose to implement? Having such a side-channel is still preferable than having to implement the feature separately in each window manager.

Do you have any readings (docs, specs, articles) to recommend on the subject?

Jason said...

Ronan: Wayland does already support a large number of optional protocol extensions. Once agreed upon, the typical place to put them is the wayland-protocols repository. You can check the GOVERNANCE document there for how standardization is handled. You may also want to read up on all available Wayland documentation and on conversations on the wayland-devel mailing list to see how this all came to be. The process of creating an extension is not simple and I wouldn't suggest trying to do it unless you are already an experienced Wayland developer and you have at least one working implementation of your extension protocol, and you are willing to help other compositor developers with their implementations.

If you're currently using wayland, you can probably already see these extension protocols installed on your system under the /usr/share/wayland-protocols directory. I should also mention that sway/wlroots already includes an unofficial protocol for querying and moving windows, however no work has been done to try to standardize it. The protocol is here: wlr-foreign-toplevel-management-unstable-v1.xml.

Anonymous said...
This comment has been removed by the author.
Plasma_User_Germany said...

Hi Peter and everyone else who reads this,
Im trying to reach out to you on a libinput feature (kinetic scroll) that has been disabled by default due to this Bug ("scroling events after scrolling ended"; Link: And didnt know which way'd be best to message you since my question is not about a bug and so I didnt wanna report one. If you read this, thanks for taking the time, I really apreciate it!

Are you by any means open to exchange some words on the potential of he kinetic scroll feature to be re-enabled in libinput? or on ways to substitute this great function in another way for system-wide kinetic scrolling in linux? To me a feature like this maximizes UX by an order of magnitudes! feels like a must have for keeping up the race with macOS and windows in terms of intuitive and easy UX. and while I read through the bug-conversation (link above) about why this feature has been disabled, I figured that I had found a way to get along with the "problem-causing behavior" and thought there was no need to disable.

any chance to talk this over? would love to see kinetic scrolling survive the transition from synaptics to libinput touchpad drivers for future use in wayland!

thanks in advance for any response! with kind regards from Germany, chris

Peter Hutterer said...

To that Anonymous user who's comments I've been deleting: criticism is fine, being rude isn't. See also:

Plasma user: kinetic scrolling already works in GTK, and I suspect Qt as well (haven't tested it). There are unfixable UX problems with having it in the driver that can easily be solved by doing the scrolling in the toolkits instead. libinput provides enough information for toolkits to do that, so tbh that discussion is basically done - it won't get added to libinput.