HiDPI aware X11 clients with Xwayland / fractional scaling
Preamble
There are already several merge requests which try to tackle the issue of HiDPI X11 clients running on Xwayland with fractional scaling:
The two last ones derive from the first one from @romangg (where many interesting points were discussed) and are slight variations of the same theme, but unfortunately none of them have yet found their way to the Xserver yet.
Both Sway (@dirbaio, @emersion) and KDE (@apol, @davidedmundson, @zzag) have branches to make use of those, whereas GNOME (@jadahl, @carlosg) hasn't enabled fractional scaling by default mostly because of this.
To be perfectly honest, the fact that there are so many of these (very similar) merge requests doesn't help with reviews and discussions, so after @apol emailed me about this being one of their biggest complaints for KDE's Wayland session, we agreed the best place to discuss these in the open would be a gitlab issue so we could all discuss in a central place. This is something I've meant to do for a long time.
This is the purpose of this (lengthy) issue, to try to summarize the current approaches, and list the various points that have been mentioned in one place or another in the past so we can hopefully proceed forward.
The purpose of Xwayland
Before we even consider the technical aspects of the problem, it's important to consider the very purpose of Xwayland.
Xwayland is a standard Xserver (which shares most of its code with other X servers such as Xorg) but also a Wayland client whose role is to allow old, legacy X11 applications which cannot be ported to Wayland native to continue to work in a Wayland environment, it's a compatibility layer for older applications such as those using Motif (which is still the industry standard) or even Xaw (e.g. xterm). I know this is obvious for all, but I think it's important to remind what Xwayland is to consider how it should adapt to the various (and orthogonal) needs we have here.
Modern applications using modern toolkits (such as GTK or Qt) will be much easier to port to Wayland as most of the heavy lifting work is already done by the toolkits which support Wayland. Those applications are also the ones which can benefit from HiDPI, older applications usually predate the advent of HiDPI.
The need for HiDPI support in Xwayland
There are notable exceptions to this, and that's the reason for the multiple attempts to get HiDPI properly supported in Xwayland with fractional scaling:
- Games on platforms without a Wayland native backend (those running in Wine or Proton with Steam for example) running fullscreen - Those can be perfectly capable of taking advantage of the native HiDPI resolutions,
- Electron apps which at this time of writing do not (yet) support Wayland natively by default (same for GOOGLE Chrome or Chromium) - But Wayland support can be enabled using some options in Ozone,
- Java applications can do HiDPI but Java has no Wayland backend yet - See the Wakefield project for a port of Java to Wayland.
The proposed solution
All 3 merge requests listed above are basically the same, they try to solve the issue by using a “global scale” applied to all Wayland surfaces for Xwayland toplevel windows (using wl_surface_set_buffer_scale()).
The same scaling is therefore applied to all X11 windows (and that's unavoidable, considering that X11 exposes global coordinates to its clients and all X11 clients share the same root window which eventually defines the size of the X11 screen which encompasses all monitors).
That basically means that allowing HiDPI aware X11 clients to render at their best will cause legacy, non-HiDPI aware X11 clients to be scaled down to a point where they can be unusable (even more so on a HiDPI monitor).
Where the merge requests differ though (I didn't check for bug fixes between them though, that's not really relevant yet), is on how to allow for both HiDPI and non-HiDPI aware clients to coexist by the way of changing the global scale factor:
- !111 sets it from the command line when Xwayland is spawned
- !432 proposes a new X11 protocol for setting the global factor
- !733 uses an X property on the root window.
But I see several problems with allowing changing the global factor on the fly:
- Who decides to change it and when? The Wayland compositor/X11 manager, based on input focus? Or the user changing a setting in their desktop environment of choice? How do regular users know if a given X11 app is HiDPI aware in the first place?
- When changing the global scale factor, all X11 clients get affected and the windows will be rescaled on screen
- XRandR events need to be emitted to notify the X11 client that the logical size of the their X11 screen has changed
- All X11 windows will all of sudden change size, possibly generating pointer enter/leave events
- And most importantly, I think this will be very confusing for the users.
Mixing HiDPI and LoDPI X11 clients
These topics where discussed between GNOME developers (including @jadahl , @carlosg, @rmader), @romangg (who filed !111) and myself, during a GNOME Shell hackfest which took place in The Netherlands in 2019 and one possible solution that would possibly solve the issue without the need of changing the global scale factor on the fly would be to have two separate Xwayland instances, one for HiDPI aware X11 clients and another one for older, legacy, LoDPI X11 clients.
https://blogs.gnome.org/carlosg/2019/10/16/gnome-shell-hackfest-2019-day-2/
That can put some burden on the X11 window manager / Wayland compositor who would need to play the proxy between the different X11 displays for things like copy/paste, drag and drop, relevant X11 properties of the root window, etc.
Another challenge with this is how to determine if an X11 clients is HiDPI aware or not, to decide on which X11 display it should be launched - A possible solution could be to use a .desktop key that the shell would use to set the appropriate DISPLAY value.
One Wayland compositor may chose to favor legacy applications and keep a scale factor of 1 (and have X11 apps blurry with fractional scaling as of today), another one may decide to favor newer HiDPI X11 clients and use a scale factor of 2 to the detriment of legacy X11 LoDPI applications, whereas yet another one may decide to take that hard path of having 2 Xwayland servers and please everyone.
But all of this remains the prerogative of the Wayland compositor (or desktop), Xwayland wouldn't be involved directly in this and I see this as a huge benefit.
An alternate solution
If we chose to ignore HiDPI aware X11 clients running non-fullscreen (assuming those will eventually get ported to Wayland natively), a simpler solution for games and X11 applications running fullscreen would be to take advantage of Wayland viewport support as with !861