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