[RFC] Wayland driver development - June 2021 update

Alexandros Frantzis alexandros.frantzis at collabora.com
Mon Jun 7 12:10:11 CDT 2021

Hi all,

For the past few months I have been working on improving the
experimental Wayland driver (original announcement here [1], first
update here [2]).

The result of this work is an update which adds several major features:

 * Vulkan support
 * Multimonitor support
 * HiDPI handling
 * Cursor clipping/relative movement
 * Wayland keymap handling

To get, build and use the Wayland driver do (note that building with
Wayland requires wayland-client, wayland-egl and xkbcommon development
files to be present on the system):

  $ git clone -b wayland https://gitlab.collabora.com/alf/wine/
  $ cd wine
  $ ./configure --with-wayland [--with-vulkan --with-vkd3d]
  $ make [-jN]
  $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...

I have uploaded a video showcasing the new features here:


Vulkan support comes with window management handling (resizing,
fullscreen etc), and can be used either directly or to implement
Direct3D through either WineD3D or DXVK.

The Wayland driver now exposes multiple monitors to Wine and supports
dynamic addition and removal of monitors. It also supports changing the
application-perceived resolution of each monitor (through compositor
scaling, see previous update [2]) to implement per-monitor mode changes.

For HiDPI handling the Wayland driver exposes a high resolution (i.e.,
the native monitor resolution) by default, and leaves it to the
application/Wine to perform any scaling (e.g., setting LogPixels). Note
that although Wayland supports per-monitor scale factors (but not
mixed-scaling for the same Wayland surface) the Wine core support for
this is not yet in place. At the moment, when windows are presented on
multiple monitors with different (Wayland) scale factors, the part of
the window in its "main" monitor is presented in high/native resolution
while other parts are scaled by the compositor. The "main" monitor for a
window changes only when that window moves fully to another monitor.

It's sometimes useful to let the Wayland compositor automatically
perform a (naive) scaling based on the monitor scale factor. This is
supported by setting the driver option HKCU\Software\Wine\Wayland
Driver\HiDPIScaling (or corresponding per app option) to "Compositor"
(the default being "Application").

To implement cursor clipping and provide relative mouse movement
(important for first person perspective games) the driver utilizes
heuristics to best map application requests to the corresponding Wayland
functionality (pointer-constraints and relative-pointer protocols).

Finally, the new Wayland keymap handling allows users to transparently
use the current keymap of their Wayland session in Wine applications
(although it doesn't allow changing it from the Wine side).


I think the driver has reached a point where it has enough features to
be useful for many use cases and also provide enough confidence that it
is a viable option going forward. My plan now is to mainly focus on
fixes/improvements and to start preparing for staging by creating a more
upstream/review friendly patchset series.

I am looking forward to any feedback or questions.


[1] https://www.winehq.org/pipermail/wine-devel/2020-December/178575.html
[2] https://www.winehq.org/pipermail/wine-devel/2021-February/181325.html

More information about the wine-devel mailing list