This patch attempts to resolve our XWayland multi dpi problem in a simple, yet effective way. More details about the technical solution are written down in the commit message of the attached commit.
Advantages of the approach are:
- HiDPI aware X clients become multi DPI in a Wayland session with a single integer scale factor being set (for example GDK_SCALE=2), independent of number of Wayland scale factors and their divisibilities.
- Small changes to XWayland.
- The necessary coordinate transformation in the Wayland compositor is a simple division/multiplication with a single integer factor independent of X client and output it is on.
- Full backwards compatibility to compositors not supporting this new functionality.
- X clients which read out the current RandR resolution to set internal options (for example games) will not be limited artificially anymore by the logical size being smaller than the real resolution.
Disadvantages are:
- In a mixed DPI setup a non-HiDPI-aware X client will look similarly tiny on all outputs, including LoDPI ones. This can be fixed for simple clients with https://keithp.com/blogs/window-scaling/
- In a mixed DPI setup all XWayland client buffers on the LoDPI output must be downscaled by the compositor. Depending on the graphics pipeline in use this can be taxing.
- Clients reading out RandR resolutions will see too large resolutions in comparison to the real mode for outputs with lower than maximum scale factor.
- While the compositor only needs to do simple transformation of coordinates, it still needs to do it for all interaction between Wayland native clients and its internal logic with XWayland. Depending on the compositor code this might be difficult.
This patch has been tested successfully together with the following KWin patch in a KWin Wayland session: https://phabricator.kde.org/D18486
You can watch a demonstration here: https://youtu.be/a8HPS3LbCCg