12 Dec
2022
12 Dec
'22
5:48 p.m.
Hi everyone!
It's been some time since our last Wayland driver update ([1]), and,
with the year coming to an end, I wanted to share information about the
progress we made this year and discuss future steps.
The focus in 2022 was on maturing the Wayland driver and keeping up to
date with the Wine upstream internal changes. This involved, among other
things, splitting the driver into a PE and Unix part, updating it for
the latest internal driver APIs, and making preparations to support
WoW64 (we are not there yet, but we are close).
A significant improvement compared to last year is support for
cross-process rendering, which is required by Chromium/CEF applications.
Last year the driver was able to run Chrome with the "--in-process"
command-line option. This year Chrome is supported without any special
flags, fully GPU accelerated on both OpenGL and Vulkan! This was
achieved by implementing what is effectively an internal off-screen
swapchain in the driver's OpenGL and Vulkan integration code, along with
a mechanism to send buffers to other processes for presentation when
needed.
This update also brings enhanced support for the linux-dmabuf v4 Wayland
protocol (aka dmabuf-feedback), which allows compositors to dynamically
send information about optimal formats and modifiers, e.g., depending on
the surface presentation mode (fullscreen vs windowed). Our new
internal OpenGL swapchain can handle such feedback directly, while for
Vulkan we rely on the Wayland WSI to provide this functionality.
This year we also made a lot of smaller scale fixes and enhancements,
that in aggregate have greatly improved driver stability. These were a
result of both testing we performed ourselves, and also of reports from
people trying out the Wayland driver, for which we are very grateful.
All the features listed in our previous update (multi-monitor, display
mode changes, copy-paste, keymaps, relative mouse etc) have been further
refined. One issue for which we haven't yet found a reasonable solution,
is how to properly position the context/right-click menu in the
standalone systray.
The Wayland driver uses the Wayland protocol in a manner that, although
in spec, exercises less well-trodden paths in compositor code.
Throughout the year we have come across a few issues with compositors,
which we have been working with upstreams to address. One issue that
people should be aware of, in particular, manifests as improper relative
mouse motion in first-person 3D games when using the Wayland driver with
some compositors (e.g., see [2]).
TL;DR of how to use the development branch:
$ git clone -b wayland https://gitlab.collabora.com/alf/wine/
$ cd wine
$ ./configure --with-wayland [--with-vulkan]
$ make [-jN]
$ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...
Especially note the use of 'DISPLAY=', which we use to opt in to the
Wayland driver by disabling the higher priority X11 driver.
Here is a video showing the latest version of the Wayland driver in
action (note that in this video I am using Mutter from git main that
includes the fix for the relative motion issues mentioned above):
https://www.youtube.com/watch?v=lZ-MK72Kyp8
---
Next steps:
Last year, due to the extensive ongoing internal rework in Wine (e.g.,
win32u), the decision was made to postpone the upstreaming of the
Wayland driver until some amount of internal stability had been reached.
My impression is that things are a lot more stable now, from the
drivers' point of view at least. Is there any upcoming work that people
feel would be severely hindered by the upstreaming of the Wayland
driver?
Ideally, I would like to start the upstreaming effort (which I expect
will take some time) at some point early next year, after the codebase
has been unfrozen. Does this sound reasonable?
Thanks,
Alexandros
[1] https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html
[2] https://gitlab.gnome.org/GNOME/mutter/-/issues/2223
16 Dec
16 Dec
7:44 a.m.
Hi Alexandros!
On 12/12/22 18:48, Alexandros Frantzis wrote:
Hi everyone!
It's been some time since our last Wayland driver update ([1]), and,
with the year coming to an end, I wanted to share information about the
progress we made this year and discuss future steps.
The focus in 2022 was on maturing the Wayland driver and keeping up to
date with the Wine upstream internal changes. This involved, among other
things, splitting the driver into a PE and Unix part, updating it for
the latest internal driver APIs, and making preparations to support
WoW64 (we are not there yet, but we are close).
A significant improvement compared to last year is support for
cross-process rendering, which is required by Chromium/CEF applications.
Last year the driver was able to run Chrome with the "--in-process"
command-line option. This year Chrome is supported without any special
flags, fully GPU accelerated on both OpenGL and Vulkan! This was
achieved by implementing what is effectively an internal off-screen
swapchain in the driver's OpenGL and Vulkan integration code, along with
a mechanism to send buffers to other processes for presentation when
needed.
This update also brings enhanced support for the linux-dmabuf v4 Wayland
protocol (aka dmabuf-feedback), which allows compositors to dynamically
send information about optimal formats and modifiers, e.g., depending on
the surface presentation mode (fullscreen vs windowed). Our new
internal OpenGL swapchain can handle such feedback directly, while for
Vulkan we rely on the Wayland WSI to provide this functionality.
This year we also made a lot of smaller scale fixes and enhancements,
that in aggregate have greatly improved driver stability. These were a
result of both testing we performed ourselves, and also of reports from
people trying out the Wayland driver, for which we are very grateful.
All the features listed in our previous update (multi-monitor, display
mode changes, copy-paste, keymaps, relative mouse etc) have been further
refined. One issue for which we haven't yet found a reasonable solution,
is how to properly position the context/right-click menu in the
standalone systray.
The Wayland driver uses the Wayland protocol in a manner that, although
in spec, exercises less well-trodden paths in compositor code.
Throughout the year we have come across a few issues with compositors,
which we have been working with upstreams to address. One issue that
people should be aware of, in particular, manifests as improper relative
mouse motion in first-person 3D games when using the Wayland driver with
some compositors (e.g., see [2]).
TL;DR of how to use the development branch:
$ git clone -b wayland https://gitlab.collabora.com/alf/wine/
$ cd wine
$ ./configure --with-wayland [--with-vulkan]
$ make [-jN]
$ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...
Especially note the use of 'DISPLAY=', which we use to opt in to the
Wayland driver by disabling the higher priority X11 driver.
Here is a video showing the latest version of the Wayland driver in
action (note that in this video I am using Mutter from git main that
includes the fix for the relative motion issues mentioned above):
https://www.youtube.com/watch?v=lZ-MK72Kyp8
---
Next steps:
Last year, due to the extensive ongoing internal rework in Wine (e.g.,
win32u), the decision was made to postpone the upstreaming of the
Wayland driver until some amount of internal stability had been reached.
My impression is that things are a lot more stable now, from the
drivers' point of view at least. Is there any upcoming work that people
feel would be severely hindered by the upstreaming of the Wayland
driver?
Probably not as large as this year's refactoring in any case. Ofc, any
user driver refactoring (and I can think already of a couple of things
I'd like to see) is hindered by additional driver implementations, but I
think it shouldn't be a blocker either.
Ideally, I would like to start the upstreaming effort
(which I expect
will take some time) at some point early next year, after the codebase
has been unfrozen. Does this sound reasonable?
I'm only giving my opinion here, I'd suggest to try and see how it goes.
Note that IMHO you'd probably be better with someone willing and
dedicated to reviewing the changes, rather than hope that review will
happen by chance or by the maintainer.
In the same way, it would also probably help if you are ready to assume
maintainership of the module from the beginning, or if someone (else
than the Wine maintainer) is.
Cheers,
--
Rémi Bernon <rbernon(a)codeweavers.com>
12:20 p.m.
On Fri, Dec 16, 2022 at 08:44:05AM +0100, Rémi Bernon wrote:
FWIW, I am happy to get involved whenever a core change requires
non-trivial driver updates (see also my comment at the end about
maintainership).
I would certainly appreciate having a dedicated reviewer (or reviewers).
I know that people's time is both limited and precious, so I would like
to make the process as easy as possible for them.
The driver commit structure, containing generally small and focused
commits, was designed with this goal in mind. The trade-off is that the
driver proposal has ended up with a lot of commits. The idea is to
iteratively propose the first of the remaining commits from the driver
that logically belong together, discuss/update/merge and continue like
this with the next commits/MR, until the whole driver is upstream.
I expect the process will take some time, that's why I would like to
start early, but that's fine. The goal is to ensure that people are
happy with and confident in what ends upstream, and I hope to learn more
myself. Hopefully this process will allow people to become more familiar
with Wayland, too.
If anyone reading this is interested in reviewing when the time comes,
please let me know :)
Hi Alexandros!
Hi Rémi!
<snip>
Next steps:
Last year, due to the extensive ongoing internal rework in Wine (e.g.,
win32u), the decision was made to postpone the upstreaming of the
Wayland driver until some amount of internal stability had been reached.
My impression is that things are a lot more stable now, from the
drivers' point of view at least. Is there any upcoming work that people
feel would be severely hindered by the upstreaming of the Wayland
driver?
Probably not as large as this year's refactoring in any case. Ofc, any user
driver refactoring (and I can think already of a couple of things I'd like
to see) is hindered by additional driver implementations, but I think it
shouldn't be a blocker either. Ideally, I
would like to start the upstreaming effort (which I expect
will take some time) at some point early next year, after the codebase
has been unfrozen. Does this sound reasonable?
I'm only giving my opinion here, I'd suggest to try and see how it goes.
Note that IMHO you'd probably be better with someone willing and dedicated
to reviewing the changes, rather than hope that review will happen by chance
or by the maintainer. In the same way, it would also probably help if you
are ready to assume
maintainership of the module from the beginning, or if someone (else than
the Wine maintainer) is.
My intention is to keep on working on and maintaining the driver. In
fact, I expect I won't be alone, as this year our "Wayland driver" team
gained two more people, who will be able to help going forward, too.
Thanks,
Alexandros
358
days inactive
362
days old
2 comments
2 participants
participants (2)
-
Alexandros Frantzis -
Rémi Bernon