Wayland maintainership

[elinorbgr]

Hi all,

I want to take advantage of the current spike of interest in winit to notify that I'd very much like to reduce my involvement in winit. I kind of accidentally became a maintainer, and it currently occupies the large majority of the time I can allocate to open source projects.

I initially started implementing the wayland backend of winit to serve as a real-world test for wayland-rs and SCTK, but now in practice I've basically put them as well as Smithay in the background behind winit. As a result I'm spending a majority of my time on winit while none of my projects really depend on it, and I'm not very happy with that.

So let it be known that I want to give my "wayland backend maintainer for winit" hat away. I don't plan to stop working on rust+wayland, and I'm willing to mentor and help anyone wanting to work on getting winit up to speed on wayland. I just don't want winit to remain my main focus in open source.

[jlogandavison]

I'm certain that there will be candidates that are better qualified than I am, but I'm interested in getting involved. Is this the place to discuss?

[murarth]

Can this be the place to discuss new maintainers, generally?
EDIT: Separate issues for each platform does make sense. Pardon my interruption.

I'm interested in maintaining the Linux X11 backend. I'm certainly not an expert on X11, but I have experience with Rust and C/C++ code and I'm willing to put the time in to get more familiar with both winit and X11.

[elinorbgr]

@jlogandavison, either here or in the glutin/winit chatroom (see #glutin on freenode IRC, or #Glutin:matrix.org on Matrix, or https://gitter.im/tomaka/glutin ) whichever is more comfortable for you. How familiar are you with Wayland in general?

---

@murarth I think it'd be easier to follow for everyone if there was a "maintainership issue" for each platform, do you agree?

---

For everyone potentially interested, I'll do a quick description of how Wayland works and how is its current integration with winit.

Wayland in general

Wayland is a protocol for windowing on Linux, pretty much like X11. It is a restart from scratch by the X11 developers themselves, to abandon all the legacy cruft accumulated and fix several design issues. (Though the question of how well Wayland was designed is not a consensual one, I'll admit).

Main differences relevant to winit are:

• Wayland does not have a single implementation (like X11 / xorg-server), but rather each desktop environment is an other display server.
• Wayland works with a set of protocol extensions. There are basically 3 protocol levels:
  • The core protocol, which covers the most fundamental functionalities and is guaranteed to be available everywhere
  • The wayland-protocols set of extensions. These are protocol extensions that have been blessed by the Wayland developers and a large part of the community, and are thus largely available.
  • Custom in-house extensions that some Wayland desktop environment support (for example Gnome and KDE each have some custom extensions). We don't have many guarantee about their availability across desktop environments.
• Wayland is in general much more oriented towards security than X11 is, and several things that winit may want to do are just not available. For example, a window cannot know where it is located on the monitor, or can only know the location of the pointer if it is currently on top of it. Similarly, the window cannot know about keyboard events if it is not focused.

Wayland with Rust

The main effort to bridge Wayland to Rust is a work of mine, wayland-rs, which is a set of relatively low-level crates that are direct bindings to libwayland and APIs for the various common protocol extensions. Winit currently uses it (wayland-client and wayland-protocols to be precise).

I've also built Smithay's Client ToolKit or SCTK in short, which is a small toolbox regrouping various common abstractions to ease the task of writing Wayland clients. Whenever some functionality wrt Wayland has been integrated with winit, I tried to split the "generic" part of it into SCTK, and only keep the winit-specific logic in winit, to improve reusability and simplify the logic of winit's wayland backend.

Wayland with winit

So, currently winit is built on top of SCTK, which notably provides the drawing of client-side decorations (thanks @trimental for his awesome work on that), keymap handling for translating keyboard events into utf8 input, and DPI-tracking for the windows.

Winit currently decides at runtime whether it'll use Wayland or X11. It first attempts to connect to Wayland, and if that fails (if libwayland is absent, or if the wayland-specific environment variables are not set), it'll fallback to X11.

Wayland's natural API is mostly oriented around callbacks, so winit plugs into these callbacks and either directly process them if they do not correspond to an event exposed to winit's downstream, or collect them into an internal buffer that is then emptied into the event loop. I chose such an implementation because was simple, not because it was optimal, so there is likely a lot of room for improvement.

[felixrabe]

Thanks for your work here! Enjoy the additional time from your reduced involvement :)

[jlogandavison]

How familiar are you with Wayland in general?

@vberger, certainly willing to learn. My experience with windowing has predominantly been writing Xlib applications in C/C++. So I am familiar with the concepts involved, but I'm not intimately familiar with the Wayland API at this stage.

Thank you for posting the summary above. Super helpful introduction to the project 👍

Looking forward to getting familiar with the internals. I'm going to begin by tackling an open issue if that's alright.

With regards to maintainership. I'd be really interested to hear more about what a maintainership involves in this project and I'm absolutely open to taking on responsibility if people deem that a worthy course of action.

[elinorbgr]

We don't have a very clear & precise definition of the role of a maintainer, but as I see it there are two main tasks:

• Be a guardian of the backend for this platform. By this I mean that no nontrivial PR to a backend should be merged without the associated maintainer approval. And similarly, the maintainer is the obvious person for a contributor to ping for guidance about how to solve an issue.
• General API discussions. Winit's API is still in flux (even though we hope to have solved the largest issues with eventloop-2.0), and is in general full of trade-offs. Each platform has its own specific assumptions and requirements, and they are regularly contradictory. There is thus a need to compromise in winit's API, to design something that works well enough in all cases.

To achieve this, I've found it to be important that the maintainers have a good understanding of the constraints of their platform, and be able to communicate them clearly with each other and the other contributors. This was quite a hard-learned lesson especially around the handling of DPI-awareness, where Wayland is quite opinionated (fractional DPI does not exist), and has a very different approach to X11 (handling logical pixels, rather than physical pixels like X11). I hope most of the debats around this kind of issues is behind us now, but I cannot say it for sure.

[kchibisov]

I'm fine with maintaining Wayland, at least fixing bugs on it from time to time and review.

I can also take a look on minor macOS PRs with the help of macOS folks working on alacritty recently.