Wayland backend: Features to implement

[DJMcNab]

In #107, we've landed the beginnings of a new wayland backend. Here are some features which need to be implemented for it, and some hints for these. This all works towards #28.

• Keyboard input - Implemented in Support composition on Wayland (and x11) #119. There are some decisions which might need to be rethought, but it should work well enough
• Pointers
  This requires several things, at different levels of complexity:
  wl_pointer object's events. Smithay-client-toolkit's abstraction over this might be sufficient for our needs.
  wl_touch - there's also a sctk abstraction.
  To support graphics tablets and pen input, see zwp_tablet_manager_v2. I believe this to be lower priority.
• Timers - in progress in Support timers on Wayland #150
  This requires adding a Timer to the calloop event loop, then removing it once the timer fires. Should be straightforward.
• Proper invalidation
  There are two levels to this, reporting it to the client, and reporting it to the compositor.
  For reporting to the application, we just need to store the requested region, and send that in paint.
  Reporting it to the server, it's unclear if we can do this. See Partial invalidation druid#402 and Present with damage region (VkPresentRegionKHR) gfx-rs/wgpu#682. The vulkan spec isn't clear¹ whether we can use the damage command ourselves
• Pop-up windows
  This is xdg_popup. This has an abstraction. We need to change a few things around in the implementation of Window - the window may either be a popup or a toplevel, but not both.
• Accessibility
  The crate to look at is accesskit_unix. This will also involve fixing AccessKit example fails to build on Linux #112.
  This can probably also be wired up to the X11 backend, as the interface appears to be relatively straightforward.
  One open question is how to represent multiple windows, but that should be the same as in all other backends
• Cursors
  That is, setting the cursor icon etc. This should use wp_cursor_shape_manager_v1 and wl_pointer::set_cursor, depending on the mode. See Cursor (shape/image) handling #136
• XDG desktop portal (file open/save, etc.)
  This should be able to share the implementation with the x11 backend
• Fractional scaling
  This requires the wp_fractional_scale_manager_v1 extension to be used. Because smithay-client-toolkit doesn't enable the staging protocols, we need to either depend on wayland-protocols directly, or work with client-toolkit to enable this
• App Menus
  A few sources report that KDE supports global menus. I think this is a dbus service, but we should integrate properly with this whatever the case may be
  This is the KDE AppMenu protocol. This appears to want to display window menus, rather than the application level menu. Is it meaningful to have it support both?
• Light and dark theme
  I believe this is a dbus API

These are other features which we need, but which require API changes across all backends:

• Clipboard
  At the moment, our clipboard API is synchronous. However, wayland's wl_data_source is async
• Monitors
  At the moment, the monitor API is global. However, I believe that the monitor API only really makes sense in the context of an Application. It's worth also asking what we expect the monitors API to be used for.
  The monitors can be accessed through OutputState
  We can also report changes in the outputs to the AppHandler.

These are other features which we need, but which require API changes (only/primarily) to support wayland

• Customise the App ID
  At the time of writing, we unconditionally set the app id to "org.linebender.glazier.user_app". We need an API to set this
• Client side decorations
  This needs its own tracking issue. We should be able to enable this on all frontends, but it's required for Wayland
• Menus of all kinds
  Right click and popup. This needs to be implemented at a higher level than Glazier. Again, the custom styles can be used on all frontends.

Footnotes

1. The wl_surface.attach, wl_surface.damage, and wl_surface.commit requests must be issued by the implementation during the call to vkQueuePresentKHR and must not be issued by the implementation outside of vkQueuePresentKHR. - https://registry.khronos.org/vulkan/specs/1.1-extensions/html/vkspec.html#platformCreateSurface_wayland ↩