[RFC] Announcing Wayland driver development

[Alexandros Frantzis]

On Wed, Dec 16, 2020 at 10:07:09AM -0600, Zebediah Figura (she/her) wrote:
> On 12/16/20 2:44 AM, Julian Rüger wrote:
<snip>
> > 
> > You should talk to our tireless and competent staging developers,
> > Zebediah Figura and Alistair Leslie-Hughes about that.
> 
> That's probably about right. I would like to be sure that a Wayland
> driver will be accepted upstream in some form or another before we take
> it—I don't want to maintain any patch set in wine-staging forever, but
> an entire graphics driver least of all.
> 
> In particular I've seen a lot of concerns about the long list of things
> Wayland can't support. Window positioning is one, but not the only by
> far. See also [1] (not that I can personally verify the veracity of any
> of these; I don't work with window managers).
> 
> [1] https://bugs.winehq.org/show_bug.cgi?id=42284#c17

Hi Zebediah,

Thank you for your comments and the link to the bug!

I would like to use this opportunity to address some of the points
mentioned in the bug report, since quite a few people may also have
similar concerns.

There is no question that the direct Wine->X11 path is likely to remain
the most capable for the foreseeable future. However, since Wayland
adoption is growing, and, by some accounts at least, X11 is becoming
legacy, I think it's worth it for Wine to begin exploring the Wayland
path. It won't be perfect in the beginning, although it may be "good
enough" for most people, and given the special weight that Wine has, it
may also help incentivize the implementation of missing Wayland
functionality in the form of new extensions.

Direct support for Wayland also provides access to modern features that
may not be available to X11 clients. An example is HDR support, which is
currently being worked on for Wayland [1], but unlikely to be supported
on X11.

---

Regarding some specific concerns:

> global keybindings, clipboard, layout switching, screen capturing,
> tray icons,

With the exception of clipboard operations, for which Wayland has an
official protocol, Wayland doesn't directly support the rest.

However, a feature not being supported by Wayland doesn't mean much
about its availability on a Wayland based system. Some features which
were previously X11 requests, are now implemented using a completely
different mechanism, mostly due to security considerations.

For example, screen capturing is already supported through the
xdg-portal mechanism on KDE, GNOME and wlroots based desktops. There are
also discussions about implementing global key bindings in a similar way,
or potentially as a Wayland protocol.

---

I think some notes on XWayland are also warranted, since some may
consider it to be a the way forward for Wine under Wayland.

XWayland is privileged in many ways, being closely integrated with
Wayland compositors. A Wayland compositor acts as the X11 window
manager, which is how absolute window positioning from X11 can work on
Wayland.

Despite its special status, XWayland is still not given free rein over
the compositor. There are many features which do not work through the
X11 protocol on XWayland, and are likely to remain that way. Here is a
list of such features that may be of interest to Wine:

  * screenshots, screencasting (except of other X11 windows)
  * global hotkeys
  * input grabs and eavesdropping
  * changing global state like "video card LUT" or video mode
  * controlling or inspecting other applications' windows (except
    possibly for other X11 apps)

Some of these features will need to be accessed through the same
alternative methods that one would need to use on direct Wayland too,
some are waiting to be implemented with a Wayland protocol or other
method, others are unlikely to ever be permitted on normal desktop
systems.

Due to the above, my opinion is that a direct Wayland driver is a
much better long-term option for running Wine on Wayland.

Thanks,
Alexandros

[1] https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/