Winit: Consider defaulting to X11 when running in Wayland

Created on 5 Oct 2017  路  6Comments  路  Source: rust-windowing/winit

I've been recently playing around with working on some projects based on winit, and as I use wayland as my primary window manager, I've been finding it frustrating.

Currently every one of my programs, before initializing winit, runs code like the following to force disable the wayland backend, and I have to manually disable it when running programs made by others:

fn avoid_winit_wayland_hack() {
    std::env::set_var("WINIT_UNIX_BACKEND", "x11");
}

This is because the wayland backend is broken to the point where it is unusable even for basic projects. Window resizing doesn't work correctly, the window doesn't size correctly, and often I end up rendering outside of the window borders. In contrast the X backend works perfectly fine.

I'd like to suggest defaulting the WINIT_UNIX_BACKEND to x11 until the wayland backend is closer to feature parity with x11. We should still allow selecting the wayland backend when possible with an environment variable, but when possible we would prefer the x11 one to provide a stable and usable experience by default.

Wayland X11 wontfix

Most helpful comment

I'd just like to clarify a few points:

First of all, a consequent part of resizing issues with Gnome have been tracked down in #163 to a mutter bug. A patch for it has been merged but I don't know if it has made it to the releases and distributions already. If this is a different bug, I'd be grateful if you opened an issue with a minimal example code reproducing the problem and details about your environment (linux distribution, desktop environment, and their versions).

This #163 story actually reflects something crutial: wayland is new for everybody, and the fact there is no longer a Single True Server as there was with X11 means bugs can be both client and server side. I've mostly tested the wayland backend against weston, the reference wayland server, and resizing works pretty well with it. But I don't have the means to easily test it with Gnome and KDE and track every issue to see if it's a winit bug or a Gnome/KDE bug.

There is something that is certain for me, it's that disabling the wayland backend by default will stick winit in a status-quo of reasonably working on wayland via Xwayland, but then having nothing to drive forward the wayland backend (my own motivation can only do so much). So, I'd like to make a double call here:

  • If you want to see winit's wayland story improve, please consider helping me working on and testing the wayland backend. I'm more than willing to explain to anybody how it works in depth (and how wayland in general works).
  • If you hit a bug with wayland that is not present with X11, please open an issue with at best a simple minimal reproducing example, or at least a link to the project using winit displaying this issue, as well as the details of your desktop environment and distribution version. This last bit is very important too, because there really are still behavior disparities.

All 6 comments

Indeed when I raised the PR for xwayland support I wrote:

It is debatable whether this should be default until the wayland code is in a better state. In any case this feature will allow me to use this lib in wayland.

It's worth noting that since this is currently an environment variable you can just set it in your .bashrc or similar, which is probably ok for use with other project examples etc.

For my own projects I default it to x11 in rust to ensure they work properly in, for example, a gnome wayland session. As such I do tend to agree that it would make sense for the current versions of winit to default to xwayland when it's available.

On the other hand, eventually wayland will be the preferred default. But I don't see a problem in upping the version when that happens and saying we default to wayland now.

I'm not sure this has been debated much yet though.

I'd just like to clarify a few points:

First of all, a consequent part of resizing issues with Gnome have been tracked down in #163 to a mutter bug. A patch for it has been merged but I don't know if it has made it to the releases and distributions already. If this is a different bug, I'd be grateful if you opened an issue with a minimal example code reproducing the problem and details about your environment (linux distribution, desktop environment, and their versions).

This #163 story actually reflects something crutial: wayland is new for everybody, and the fact there is no longer a Single True Server as there was with X11 means bugs can be both client and server side. I've mostly tested the wayland backend against weston, the reference wayland server, and resizing works pretty well with it. But I don't have the means to easily test it with Gnome and KDE and track every issue to see if it's a winit bug or a Gnome/KDE bug.

There is something that is certain for me, it's that disabling the wayland backend by default will stick winit in a status-quo of reasonably working on wayland via Xwayland, but then having nothing to drive forward the wayland backend (my own motivation can only do so much). So, I'd like to make a double call here:

  • If you want to see winit's wayland story improve, please consider helping me working on and testing the wayland backend. I'm more than willing to explain to anybody how it works in depth (and how wayland in general works).
  • If you hit a bug with wayland that is not present with X11, please open an issue with at best a simple minimal reproducing example, or at least a link to the project using winit displaying this issue, as well as the details of your desktop environment and distribution version. This last bit is very important too, because there really are still behavior disparities.

@vberger I get a decent amount of Wayland interest on Alacritty; would you be open to having your call to action in a Wayland section of the Alacritty README?

Yes, please do!

Wayland support is clearly very far from ready to use. Preferring X11 by default would be better than letting everyone face a lot of issues, spend a lot of time to examine them and eventually find this discussion telling they have to set this environment variable.

As of the recent release of winit, most issues with wayland support should be fixed, so I'll close this.

Was this page helpful?
0 / 5 - 0 ratings