Xwayland

Xwayland is a fully fledged X server implementation that act as a proxy between X11 clients and a Wayland compositor. It runs as a specialized Wayland client, while optionally using a set of Xwayland specific Wayland protocols for implementing certain functionality. The Wayland compositor acts both as the Wayland display server Xwayland connects to, as well as the Window Manager.

Multi DPI

On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor.

Multi DPI intends to allow clients to seamlessly move around on a display with multiple monitors connected, where each monitor may have very different DPIs, thus different scales, without any sudden size changes or glitches, while at the same time allowing clients to switch between different scaling factors.

For X11 clients via Xwayland, without various alterations, it is not possible to seamlessly switch between different scales, however, potentially without changing the client. we might be able to achieve seamless moving around as well as well as HiDPI drawing, except that clients will either always be HiDPI or LoDPI, instead of being able to switch between them as Wayland clients can.

Currently there are three potential implementation paths for enabling multi DPI Xwayland client support. The three are described below.

Compositor side monitor layout representation

The compositor side monitor layout depends on the configured scale the connected monitors have. The assumption is that each monitor has a potentially non-integer framebuffer scale, but always a integer logical size. The internal compositor display coordinate space is always in logical pixels.

Examples:

• A monitor with the physical pixel resolution 3840x2160, configured with the scale 2, has the logical size 1920x1080.
• A monitor with the physical pixel resolution 3840x2160, configured with the scale 1.5, has the logical size 2560x1440.

Multiple monitors are laid out in the logical pixel coordinate space according to their logical size.

For example, assume you have three monitors, A, B and C, with the physical resolutions 1920x1080, 2880x1620 and 3840x2160. Each one of them roughly have the same physical size. Lets assume Monitor A will have the scale 1, B 1.5 and C 2. This means all three will have the logical size 1920x1080. When laid out linearly next to each other, in the display coordinate space, it will look as this:

   +-----------+-----------+-----------+
   |           |           |           |
   |     A     |     B     |     C     |
   |           |           |           |
   |           |           |           |
   +-----------+-----------+-----------+

xdg_output will expose the following layout (WIDTHxHEIGHT+X+Y)

• A: 1920x1080+0+0
• B: 1920x1080+1920+0
• C: 1920x1080+3840+0

and the logical screen size will be 5760x1080.

Xwayland multi DPI

For X11 clients connected via Xwayland, in the above monitor layout representation, it is currently not possible to display HiDPI clients properly, as today Xwayland always assumes client windows are of scale 1. For a Wayland compositor, this means that such a window will be scaled up when displayed on a scale=2 monitor.

There are currently three alternative approaches for dealing with this. Each approach has one thing in common: transformation of input/output coordinates and dimensions from/to X11 clients (via plain X11 as well as EWMH etc).

Window Manager level window transformation

The idea with window manager level window transformations is to allow the window manager (thus the compositor) to detect what windows are HiDPI, and then apply various transformations on said windows. Among other things it needs to:

• Detect when a window wants to be maximized, then reconfigure the window size to the actual maximized size (usually significantly larger)
• Detect when a window wants to be fullscreen, then reconfigure the window size to the actual fullscreen size (usually significantly larger)
• Detect when a window wants to be positioned in a certain way (e.g. centered, restored position), then reconfigure the window position to what was intended by the client
• Detect when a window is a popup menu, then reconfigure the popup window position to have the correct relative position
• Detect when a window is a popup menu, but is constrained by the monitor region, then reconfigure the popup window position to the actual constraint.
• Detect when a window is a popup menu positioned relative to a previously reconstrained popup menu, then reconfigure the popup window position accordingly

+/- of this approach

• + No significant changes needed to Xwayland
• + Potentially easy to handle fullscreen games while allowing them to be drawn with the target framebuffer size
  • !!! DPI aware applications (such as a fullscreen PDF viewer) should draw to a framebuffer the size of the target framebuffer to get the correct scaling
• + Possibly easy to add/remove "scales" on the fly
• - Could be extremely hard to catch all the edge cases related to parent-child related positioning and monitor constraint
• - "Initial good size" used in GTK+ and possibly elsewhere might be unfixable

Multiple X11 screens

Open up multiple X11 screens, one for each possible scale. Each screen transforms the xdg_output layout given the scale of the screen (1 or 2 most likely). A client would either connect to the HiDPI screen, or the LoDPI screen, and the compositor would transform coordinates accordingly.

+/- of this approach

• + Few significant changes needed to Xwayland
• + No arbitrary estimation of client "intents"
• + Could potentially be combined with WM hints for the fullscreen game case to avoid scaling
• - The compositor will need to act as middle man between the screens, just as it is the middle man between X11 and Wayland
• - No way to add/remove scales on the fly, A screen is either there or its not
• - Clients need to know what screen to connect to
• - Would likely run into various worm cans as this has never been the intention of screens
• - Mutter hasn't supported multiple screens some time, GTK+ support limited

Multiple hidden X11 screens

This idea is about adding a new concept to the Xorg server: hidden screens. They are similar to regular X11 screens, but not visible to the client. It should be possible to add/remove them on the fly, and assign them to clients without the client making the decision itself.

The functionality of the hidden screen would be to transform monitor and screen dimensions in the same way as the different screens would, possibly via some kind of filter functionality.

+/- of this approach

• + No arbitrary estimation of client "intents"
• + Potentially able to add/remove scales no the fly
• - Significant changes needed to Xwayland
• - Xwayland would need to do various non-coordinate transformations (such as scaling windows when window content is retrieved between clients on different screens)