xwayland: add hidpi support via xwayland scale command

[Dirbaio]

This PR adds an xwayland scale N command that sets a "global scale factor" for xwayland apps to N.

This causes all xwayland windows to be rendered at that scale. If a window is then displayed in an output with different scale, it is scaled so that the text is the correct size. Text looks best when rendered with matching scale.

This allows the user to choose on which output the text looks best if they have outputs with different scales.

Default xwayland scale is 1, which matches the previous behavior.

This requires xserver patches from https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432
This requires wlroots patches from swaywm/wlroots#2064

Read the wlroots PR for technical details on how the scaling works.

[jbeich]

Can you document xwayland scale <N> in sway/sway.5.scd? Also, -Dxwayland=false build fails (see f98ca3a for a rough fix):

../sway/commands/xwayland/scale.c:23:12: error: no member named 'xwayland' in 'struct sway_server'
        if(server.xwayland.wlr_xwayland != NULL) {
           ~~~~~~ ^
../sway/commands/xwayland/scale.c:24:3: error: implicit declaration of function 'wlr_xwayland_set_scale' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                wlr_xwayland_set_scale(server.xwayland.wlr_xwayland, scale);
                ^
../sway/commands/xwayland/scale.c:24:3: note: did you mean 'xwayland_cmd_scale'?
../sway/commands/xwayland/scale.c:7:21: note: 'xwayland_cmd_scale' declared here
struct cmd_results *xwayland_cmd_scale(int argc, char **argv) {
                    ^
../sway/commands/xwayland/scale.c:24:33: error: no member named 'xwayland' in 'struct sway_server'
                wlr_xwayland_set_scale(server.xwayland.wlr_xwayland, scale);
                                       ~~~~~~ ^
3 errors generated.

[zsolt-donca]

I have an issue with the code present in this MR: the mouse cursor is really tiny for me in the XWayland clients. The cursor appears half the normal size, or maybe even less. I am using xwayland scale 2 and one of my outputs has scale 1.5, the other 2.0. The cursor appears very small on both. I already brought this issue up in swaywm/wlroots#2064 (comment) where I included further details, and got the answer swaywm/wlroots#2064 (comment) stating that it is the Wayland compositor/DE, such as sway, that sets the very small cursor. I indeed managed to confirm this by setting XCURSOR_SIZE=48 before launching an affected app, and the cursor appeared normal.

Does anybody has any idea on this? If somebody could point me into the right direction as to where to look for this in the code, I'd be willing to do some testing and maybe come up with a fix. I imagine that this shouldn't be that big - after all, I suspect it's just that the default cursor size should be multiplied by the xwayland scale factor.

[progandy]

If you set a global xwayland scale factor, then you should set a similarly scaled cursor size with an xsettings daemon (Gtk/CursorThemeSize) and xrdb (Xcursor.size) just like you set higher dpi. (Keep XCURSOR_SIZE unset I think)

[zsolt-donca]

@progandy That's what I am doing. I think that the issue is that XCURSOR_SIZE is being set by sway itself (to 24) - if I unset it, my XWayland-clients have the proper mouse cursor size (probably though the xsettings you also mentioned). I don't have any references to it in my zshrc file, but the variable is still being set, and I can only think of sway.

Can somebody confirm if sway indeed set XCURSOR_SIZE?

[yegorius]

I confirm: on my system apps that run under Xwayland have XCURSOR_SIZE=24 despite me not setting it anywhere.

[yegorius]

BTW, Xwayland process also has XCURSOR_SIZE=24

[progandy]

Can somebody confirm if sway indeed set XCURSOR_SIZE?

Yes, I completely forgot that:

sway/sway/input/seat.c

Line 921 in 0704248

setenv("XCURSOR_SIZE", cursor_size_fmt, 1);

(fixed link)
Wayland doesn't have any better way to set the cursor size for wayland clients, so sway will need to handle scaling for xwayland or the whole cursor situation will have to be improved somehow.

[zsolt-donca]

Thanks for the pointer, @progandy !

Browsing through the code I found that the value of the XCURSOR_SIZE variable can be controlled through the default seat seat0; quoting from man sway-input:

seat xcursor_theme []
Override the system default XCursor theme. The default seat's (seat0) theme is also used as the default cursor theme in XWayland, and exported through the XCURSOR_THEME and XCURSOR_SIZE environment variables.

And adding the following to sway's config actually sets the correct cursor size to XWayland clients:

seat seat0 xcursor_theme "Adwaita" 48 

... but it has the unintended consequence of making the cursor huge in several applications, most notably in sway itself (when on an empty workspace, or when the cursor is over the window decorations). This was unexpected to me, because it says xcursor_theme.

Is there a way to set the correct cursor size in non x-wayland app while using the above setting for the xwayland apps? Is this even an intended behavior?

As another line of thought, I am wondering if it was a good idea to apply the value of xwayland scale to the default value of cursor size (24), as hardcoded in the code: following:

sway/sway/input/seat.c

Line 906 in 0704248

unsigned cursor_size = 24;

What do you think? If somebody could confirm that this was a good idea, I could start looking into it, and maybe come up with a pull request for this branch.

[zsolt-donca]

The cursor size issue is bigger than I thought. I don't think that it can be fixed just by setting the right value to XCURSOR_SIZE. For testing purposes, I tried a code version that leaves cursor_size and the seat cursor size to their default (24), but sets XCURSOR_SIZE to 48, effectively doubling the value, as both my xwayland scale and sway output scales are also 2. The result: the cursor is correctly sized in xwayland clients, in sway itself, and in most GDK-based applications, but the cursor is double the normal size in Qt-based apps (even though they are running in wayland-native mode) and in various other apps, such as kitty and alacritty. Apparently, these affected apps pick up the value of XCURSOR_SIZE, and since they are running in wayland-native mode, the cursor size is already scaled (according to my output's scale factor), so the cursor is scaled twice.

I think the cursor size variable XCURSOR_SIZE needs to stay the default, and it should be handled in a lower-level, maybe in wlroots or xwayland. Any thoughts from people more knowledgeable than me?

[sjnewbury]

The cursor size issue is bigger than I thought. I don't think that it can be fixed just by setting the right value to XCURSOR_SIZE. For testing purposes, I tried a code version that leaves cursor_size and the seat cursor size to their default (24), but sets XCURSOR_SIZE to 48, effectively doubling the value, as both my xwayland scale and sway output scales are also 2. The result: the cursor is correctly sized in xwayland clients, in sway itself, and in most GDK-based applications, but the cursor is double the normal size in Qt-based apps (even though they are running in wayland-native mode) and in various other apps, such as kitty and alacritty. Apparently, these affected apps pick up the value of XCURSOR_SIZE, and since they are running in wayland-native mode, the cursor size is already scaled (according to my output's scale factor), so the cursor is scaled twice.

I think the cursor size variable XCURSOR_SIZE needs to stay the default, and it should be handled in a lower-level, maybe in wlroots or xwayland. Any thoughts from people more knowledgeable than me?

The inconsistencies are almost certainly bugs due to the fact that various compositors have inconsistently applied scaling to cursors using various variables. As far as I can tell it isn't clearly documented on freedesktop.org. It is a tin of worms, but it does need addressing. I see incorrectly sized cursors quite often under sway (x2 scaling) without any patches or hacks so it doesn't entirely work anyway as it is, I'm not sure it's really worse with your patch, it just exposes some of the problems more clearly. IMHO, x-cursor size should be separable from wl-cursor size.

[Eitetsu0]

Wow . This would be perfect for me if it could accept a fractional scale value like xwayland scale 1.5 .

[nlgranger]

@Eitetsu0 fractional scaling is not supported by xwayland AFAIK and the point of this PR is just to expose the scaling value as a config option instead of letting sway choose it based on an heuristic.

[1player]

Discussion of the xserver patch has moved here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1318, where it lists three alternative ways of dealing with this problem.

KDE has confirmed they integrated something like it in their compositor, would this PR work with any of these recent developments? I haven't followed to closely, I'm just holding off on the sidelines waiting for anything that deals with this to get merged before I can use Sway on my workstation, and it seems momentum has been lost.

[manio]

Hi,
Can we force unscaled XWayland apps with this PR when sway have scaling set for some specific display/monitor?

This is my biggest problem with sway nowadays (I have a HiDPI display with scale set to 2 and I want all my XWayland apps to have it unscaled while wayland-native apps are OK for me).

The Hyprland have a really great solution for this:
https://wiki.hyprland.org/Configuring/XWayland/
It just works out of the box without patching XWayland.

[almindor]

Bumping since this is now 4 years old. I'm also highly curious if something like the above comment could be done. Would we need external upstream patches to disable Xwayland scaling completely like hyprland does it?

[manio]

I think I've heard that the Sway authors won't do it, but as a side effect, for the last year, I've collected all the software that isn't working and started a crusade to fix it or at least inform authors about the problem:
libsdl-org/SDL#8768
glfw/glfw#2457
FreeRDP/FreeRDP#9715
and lastly:
SoftFever/OrcaSlicer#7902

I know this is a long process, but I hope Xorg will die anyway :)

[1player]

I know this is a long process, but I hope Xorg will die anyway :)

Expecting Xorg to die, which has been around for decades instead of applying a user-friendly work around is a quixotic and, with all due respect, stubborn decision. The thing is, more time passes, the less it makes sense to fix it and sway solidifies in its decision to wait for the magical day no one uses Xorg anymore. The best time would've been 6+ years ago when the problem first emerged. I know it's annoying as a user that has been waiting almost a decade to use sway; but my eyes are too precious to suffer blurry windows or unscaled UIs because of this frankly silly decision.

In any case, I want to leave a token of appreciation to @manio for his crusade against windmills against software that is still stuck in the 90s.

[ilya-epifanov]

@manio add to this pretty much all Java apps. IDEs, DAWs, matlab. Sadly all of them look like crap in sway

[manio]

@ilya-epifanov Yeah, fortunately I don't need to use any java-crap daily :)
But I remember that I had to run IntelliJ IDEA like this:
_JAVA_AWT_WM_NONREPARENTING=1 /opt/idea/bin/idea.sh to have it working in Sway,
but it was before I moved to neovim for working with Rust code.
But of course I am aware that there are plenty of good java-written soft (like e.g. Ghidra) which could be cool to have full scaling support under sway...