GitLab

The way Xwayland works (like all Wayland clients), it first queries the Wayland registry, set up all relevant protocols and then initializes its own structures.

That means Xwayland will get the Wayland outputs from the Wayland compositor, compute the physical size of the combined outputs and set the corresponding Xwayland screen properties accordingly.

Then it creates the X11 screen using fbScreenInit() but does so by using a default DPI value of 96. That value is used to set the physical size of the X11 screen, hence overriding the value computed from the actual physical size provided by the Wayland compositor.

As a result, the DPI computed by tools such as xdpyinfo will always be 96 regardless of the actual screen size and resolution.

However, if the Wayland outputs get reconfigured, or new outputs added, or existing outputs removed, Xwayland will recompute and update the physical size of the screen, leading to an unexpected change of DPI.

To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can be set using the standard command lime option "-dpi") and compute a physical screen size to match that DPI setting.

Note that only affects legacy core protocols, X11 clients can still get the actual physical output size as reported by the Wayland compositor using the RandR protocol, which also allows for the size to be 0 if the size is unknown or meaningless.

Note : The XRandR reported would remain the same as the Wayland output, i.e. if the Wayland compositor chose to report 0, the corresponding XRandR size will also (still) be 0 - If a client uses the XRandR value and is unable to handle a size of 0, this a more of a client bug because RandR allows for the physical size to be 0:

'widthInMillimeters' and 'heightInMillimeters' report the physical size of the displayed area. If unknown, or not really fixed (e.g., for a projector), these values are both zero.

Closes: #731 (closed)