The ideal Wayland backend

[i509VCB]

In the process of unpiet, the Wayland backend needs some work under the hood as well. Since the backend is relatively immature, I'd recommend a rewrite of the Wayland backend while we are in progress with unpiet.

I may contribute some bits here and there in the future, but I am quite busy so I'll lay out the future ideal state of the Wayland backend:

A few implementation notes that would be useful:

• Wayland and X11 effectively have the same keymap logic under the hood. It would be prudent to have this code shared between the two backends, but this comes at the cost of writing your own keyboard boilerplate (vs using what smithay's client toolkit has).
• Use wayland-rs 0.30. Yes these are beta versioned crates, but 0.29.x is going away soon.
• Continue using calloop under the hood. In particular, try to create a high precision event loop so that Linux can use timerfd which is more accurate than thread based timing.
• Use smithay's client toolkit.
  • This should help with reducing some of the implementation boilerplate

And some implementation advice for fulling the scope of glazier:

• Window creation, including subwindows
  • Using xdg-shell's xdg_toplevel and xdg_surface
• System menus
  • Wayland doesn't really have a concept of a system menu and nor does X11. The DBusMenu for dbus could be used to support this, but users would have to be responsible for rendering in the case that the DBusMenu isn't made visible via the compositor for example.
  • For popup based menus, Wayland provides no assistance here. Effectively treat it like a window with special semantics.
• Keyboard events
  • wl_keyboard, possibly some seat related stuff
• Input Method Editor
  • See the zwp_input_method_v1 protocol
• Mouse, pointer (touch and pen) events.
  • wl_pointer (for mice), and the tablet-unstable-v2 protocol for drawing tablets.
• Cursors (including custom images)
  • Part of core wl_pointer.
• DPI Info
  • At the time of writing, only integer scales. This will change in the future given 3 proposals to add fractional scaling.
• Clipboard
  • See wl_data_device
• File dialogs
  • ashpd like current druid-shell.
• Frame pacing
  • Not fully baked, this seems to explain how that will go for clients which don't want a mailbox only presentation model: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/65

The general philosophy is that a task is in scope if it requires deep integration with the platform and is not easy to separate out as a separate library that layers on top of Glazier.

A few things worth discussion here include:

• Client side decorations (including allowing the user to only have CSD, use it as a fallback or fully commit to server side decorations)
  • If libdecor is considered, note that libdecor acts more like a shell than a set of decorations. Plus some issues with libdecor need to be ironed out before it is safe to use in Rust (some callbacks in libdecor are reentrant).
• Primary selections (Think X11 middle-click to copy a selection in another window)
• Idle inhibition (using the new idle-inhibit protocol)
• xdg-activation (XDG_ACTIVATION_TOKEN)

There are some less clear, but nice things we could support that are more Wayland specific:

• The layer shell, this may become a privileged protocol in the future, restricting what clients can use the layer shell per compositor policy. This has use for system docks and bars on Linux.

[richard-uk1]

Thanks for writing this up. I'd be interested to see how we could work with smithay client toolkit given that it exists to make client code easier. Do we lose anything? If not, it's probably the way to go?

[i509VCB]

Smithay's client toolkit (sctk) is intended to provide composable components to implement some aspect of a client. Likely glazier will use sctk internally as developers using glazier probably don't need to too far under the hood.

For the keyboard integration, you probably should use the built-in calloop event source to handle repeat events nicely assuming you don't choose to share keyboard logic with x11.

For shells, sctk simply manages all the dirty configure logic and gives you a single notification with a non-exhaustive type to get info from. For other protocols that integrate into the configure sequence, we do provide the serial to assist with that, meaning further xdg-shell extensions should be possible. From the configure sequence, glazier can dispatch whatever events are needed.

Creating a window currently kind of takes over the initial commit sequence. This will change as winit also has this issue. I have some work locally I need to finish for that.

The data device stuff for 0.30 sctk is nearly done, it provides helpers and a way to wait for the write from the other clients or server to be done.

Of course sctk for 0.30 is still a bit wip (once we iron out sctk 0.30, wayland-rs 0.30 will be released) so we are willing to accommodate glazier where needed.

[wash2]

If there is help wanted for using sctk in the wayland backend, i'd be happy to contribute :)

[jneem]

Yes! I've been poking at this, but very slowly because I haven't had much time. I just pushed my not-even-building WIP to here, and also an sctk+vello demo here. I'm happy to give you write access to those forks if you want to poke at it together, but given the current state I also won't be offended if you want to start your own fork.

[wash2]

Ok, I'll take a look at what you've got. I'll probably work on my own fork though :)

[dvc94ch]

I remember simthay client toolkit missing quite a few features like support for layer-shell, changing the cursor bitmap, multi seat handling etc. That was about 5y ago, maybe things changed. I wrote my own implementation, mostly for fun then. Not sure if any of it is still relevant or useful.

• [0] https://github.com/dvc94ch/linux-toolkit/tree/master/src/wayland

[PolyMeilex]

I remember simthay client toolkit missing quite a few features like support for layer-shell

Currently, that's not a problem at all, sctk is just a bunch of helpers, you can implement any protocols you want, even private ones without the need for it to be supported upstream, layer shell is just so simple that there is nothing to abstract away. You just plug it's surface to sctk WlSurface module and that's it. That being said, it is abstracted away in the current version anyway, mostly because ext_layer_surface will probably become a thing at some point, and then sctk users will get support for it for free.

changing the cursor bitmap

Supported, and even if it was not, you can just pass sctk WlSurface to WlPointer::set_cursor manually and call it a day.

multi seat handling

Supported