Roman Gilg authored Jan 17, 2019 and Dario Nieuwenhuis committed May 02, 2020

To benefit from Wayland's multi DPI capabilities in XWayland a global scaling
factor is introduced, which is applied to all outputs.

The RandR size of an output is calculated by the (integer-)multiplication of
this global scaling factor with its logical size received via the xdg-output
protocol.

In other words the size of any RandR screen corresponds to the mode size of
its wl_output multiplied with the quotient of global scaling factor divided by
the compositor's internal output-dependent scaling factor.

HiDPI aware X clients can then provide Pixmaps enlarged by the global scaling
factor and the Wayland compositor is supposed to downscale these buffers on
outputs scaled by less than the global scaling factor.

A Wayland compositor needs to scale all X communication in its XWM part by the
global scaling factor, such that X windows have the correct geometry.

In summary:
* All positions in Wayland internal communication must be carried out by the
compositor in logical coordinates, i.e. in its compositor space.
* All positions in X internal communication are based on RandR sizes.
* All positions in Wayland to X communication must be multiplied by the global
scaling factor.
* All positions in X to Wayland communication must be divided by the global
scaling factor.

In order to not break compositors that do not support these transformations,
the global scaling factor is set to 1 by default, which behaves the same as
before. The compositor must explicitly set the global scaling factor via the
new XWAYLAND protocol. Changing the scaling factor on the fly on a running
X server is supported.

[dirbaio@dirbaio.net: fix incorrect scaling in a few places]
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Signed-off-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>