[RFC] Announcing Wayland driver development

[Aaryaman Vasishta]

This is super amazing. Thank you very much for this contribution to WINE! I
can't wait to try this.

Cheers,
Aaryaman

On Wed, Dec 16, 2020 at 2:16 AM Alexandros Frantzis <
alexandros.frantzis at collabora.com> wrote:

> Hi all,
>
> For some time now I have been working on a Wayland driver for Wine, and
> it has now reached a good enough state to present it to the wider
> community.  This driver allows users to run Windows GDI and OpenGL
> applications directly on Wayland compositors without an intermediate
> layer to translate from X11 to Wayland. This leads to a leaner and more
> efficient stack.
>
> The code currently resides at:
>
>     https://gitlab.collabora.com/alf/wine/-/commits/wayland
>
> Get it with:
>
>     $ git clone -b wayland https://gitlab.collabora.com/alf/wine/
>
> Configure with (you need the wayland-client and wayland-egl packages):
>
>     $ ./configure --with-wayland
>
> To run, ensure there is a Wayland compositor running, unset DISPLAY (so
> that Wayland is picked instead of X11) and set WAYLAND_DISPLAY (if
> needed):
>
>     $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...
>
> Here is video showcasing a few Windows applications running with the
> Wayland driver on the Weston reference compositor:
>
>     https://youtu.be/br2b8gUy5n8
>
> The Wayland protocol is by design more constrained compared to more
> traditional display systems like X11. These constraints add some
> special challenges in the integration of Wayland with Win32.
>
> Since Wayland's window model is not based on a single flat 2D
> co-ordinate space, as X11's was, the Wayland protocol doesn't allow
> applications to control their absolute position on the screen. For Win32
> transient windows (menus, tooltips, etc) the driver tries to work around
> the lack of absolute positioning by "anchoring" them to an owning
> Wayland surface and treating them as subsurfaces of that owner. Screen
> coordinates for such windows are transformed to local coordinates
> relative to the owning surface, allowing correct placement through
> relative subsurface movement, which is supported by Wayland. By using
> heuristics to select the proper owning surface, this approach has led to
> very good results.
>
> Absolute positioning of non-transient top level windows is not supported
> at this time, and will likely require a (possibly controversial) Wayland
> extension if it is to ever be pursued. The lack of absolute positioning
> also has an adverse effect on input handling, when parts of windows
> reside outside the visible windows display space, but are still full
> accessible in the Wayland compositor display space (and thus the user).
> Input events to such areas don't reach their intended coordinates (are
> clamped to Windows display bounds) leaving the user mystified about why
> they are unable to interact with a perfectly visible area in their
> Wayland compositor. The current partial workaround is to force all
> windows at (0,0) windows display coordinates, to maximize the area which
> can be interacted with. With this workaround, and as long as windows
> remain smaller than the display size, input works without issues.
>
> Here what's supported at the moment (modulo bugs):
>
> * GDI apps, including layered/translucent windows
> * OpenGL apps
> * Window resizing
> * Maximized and fullscreen window states
> * Mouse and keyboard (only QWERTY) input
> * Mouse cursors
> * Menus, tooltips, etc
> * Single display
>
> What needs more work (or is completely missing):
>
> * Minimize
> * Better z-order and activation handling
> * Keyboard layout support
> * Grabs
> * GTK menu mouse handling bug (cannot click to select items)
> * Multiple displays
> * Vulkan. Note that that there is another effort at
>   https://github.com/varmd/wine-wayland/ focusing solely on vulkan.
>   My hope is that we will be able to share efforts going forward.
>
> Programs I have tried and which are working well (again modulo bugs):
>
> * Native Wine/Win32 apps (notepad, regedit etc)
> * Supertuxkart
> * 010Editor
> * Firefox
> * Stellarium
> * Battle For Wesnoth
> * GIMP (except clicking items in GTK menus as noted above)
> * Unigine Valley
>
> My first question to the Wine community is how complete the driver
> should be before being considered for inclusion. Is the current Wayland
> driver state enough? If there is interest, I was hoping to get the
> driver in earlier rather than later, in an experimental capacity, in
> order to provide a single, official point of development for people
> wanting to contribute.
>
> My second question is about the best way to move forward with
> upstreaming. The code is currently split between just a few commits,
> mostly as a result of the experimental nature of this effort, and also
> because I used existing code from winex11 and wineandroid as my starting
> point. I would like to split this into smaller commits to make it more
> review-friendly for the mailing list. I was thinking of splitting by
> user32 function (and internal dependencies), but since this is going to
> be an artificial split, I am open to other ideas to make reviewers'
> lives easier.
>
> Looking forward to your feedback and questions!
>
> Thanks,
> Alexandros
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201216/61a2a6ba/attachment.htm>