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).
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-c...