HiDPI support: add option to only scale Wayland-native programs

[RuiAlias]

In this issue I'll describe a problem (that I have) with sway's HiDPI support and a suggestion of a solution.

Problem

I use a single monitor, that is HiDPI, and I can't have every application scaled properly unless I use the default scaling of 1 and configure each application separately.

If I am using i3, I only need to set the Xft.dpi property of Xresources (Xft.dpi: 192 for a 2x scale) to scale every program properly, i.e. no blurry text.

However, in sway, setting the scale property (output <name> scale 2 for 2x scale) scales some programs nicely and makes the others twice as big but blurry. As far as I can tell, the blurry programs are X-native and the properly scaled programs (i.e. not blurry) are Wayland-native.

native-scale configuration option

My suggestion is to add the option of not scaling the non Wayland-native programs, i.e. scale only what can be scaled properly (the native Wayland programs) and let the user deal with the other programs. This would result in a native-scale output option. If this is implemented sway's users would be able to have properly scaled X-programs by setting Xft.dpi and properly scaled Wayland-programs by setting native-scale in sway.

Multi-monitor users

Multi-monitor users could (1) keep using scale, ignoring this new option, or (2) use native-scale for Wayland-programs and use something X-specific that is able to scale X-programs according to the monitor it's being displayed at (not sure if this exists).

[ddevault]

I would rather not add features which worsen the Wayland experience for the sake of the X experience.

[RuiAlias]

I don't see how native-scale would worsen the Wayland experience, perhaps my explanation wasn't clear enough. If someone uses only Wayland-native programs (which I'm all for), native-scale would be identical to scale and those users wouldn't need to change their config as I'm not proposing the removal of or changes to scale.

The only effect I can see this having for "Wayland only" users would be the extra option in the manual and the extra "unnecessary" code in sway. (But sway supports XWayland to begin with.)

[ddevault]

Well, it's more complex than you think. Trust me, we've thought about it.

[emersion]

I'd rather add a config option to set the global Xwayland scale factor instead.

But that doesn't solve the issue. All coordinates (input events, output layout, menus, popups, etc) will be messed up.

[RuiAlias]

I assumed this was relatively easy to implement since I interpreted it as "scale with less features" (i.e. without the "stretching" of X-programs) but I believe you.

Thanks anyway.

[maximbaz]

I've seen that GNOME managed to scale properly XWayland apps, so that no apps are blurry with HiDPI, neither native Wayland nor old XWayland apps. Does anyone know how they managed to achieve this? I really really want to switch to Wayland + sway, but although using only Wayland apps is a noble goal, in practice this is not feasible today, so I would have to use some XWayland and I can't use them if they are blurry and/or not properly scaled.

[RuiAlias]

I don't know how they have implemented it (I haven't tried GNOME), but I can tell you that it's possible to use Sway today with both Wayland and X native programs scaled properly, because that's what I'm doing.

The solution consists in:

• Setting Sway's scale to 1 (default), i.e. removing Sway from the equation;
• For Wayland apps: configuring each Wayland application "by hand" (either by increasing the font size or by setting some environment variable);
• For X apps: using the Xft.dpi property of Xresources.

This is obviously not an ideal solution and it doesn't work in a mixed DPI setup (more than one monitor with each having a different dpi / scaling factor).

@maximbaz Does GNOME scale both XWayland and Wayland apps properly in a mixed DPI setup?

[maximbaz]

I don't have a way to test mixed DPI, so I don't know...

Thanks for sharing your approach, yes it's less than ideal, but I see now why you created this issue in the first place - if there was a way to ignore scaling XWayland apps / set XWayland scale factor to 1, you could have focused on manually hand-crafting X applications while having awesome experience with Wayland native apps, but right now your experience is completely opposite, you have to manually configure Wayland apps.

[tareefdev]

@RuiAlias Thanks your solutions worked with me too

[scarlehoff]

@RuiAlias This basically cripples one of the advantages of wayland wrt X11, which is support for hidpi in a multimonitor set up.

What gnome currently does (and imho is the correct behaviour alhought it seems @ddevault and @emersion disagree with me on this) is setting the scale of all X11 to 1 (or 2 or whatever number) and keeping it fixed.

Adventage: not blurry
Disadvantage: tiny text in the HiDPI screen.

To me is better to have tiny but not blurry text since I always can increase the text size but can’t undo the blurryness.

I was going to open an issue commenting exactly this, since I see the issue is closed I imagine there is no interest in this. Just a question, is this by choice or is it just something you guys see no worth doing?
Also: is there a known way of doing this already? (i do not want to waste my time reinventing the wheel or trying to write a feature that is explicitly not wanted)

Thanks!

[emersion]

What gnome currently does (and imho is the correct behaviour alhought it seems @ddevault and @emersion disagree with me on this) is setting the scale of all X11 to 1 (or 2 or whatever number) and keeping it fixed.

This isn't as simple. But GNOME has a global coordinate space with scaled physical units, and this makes partial Xwayland HiDPI support possible (though this brings other issues as well and makes some features impossible to have).

Just a question, is this by choice or is it just something you guys see no worth doing?

It would just be very difficult to get right and maintain. No, it's not as simple as "just don't scale apps", as already explained before.

[progandy]

Ideally wayland applications would use monitor independent units (points, mm, inches) and automatically scale their GUI to the detected monitor dpi instead of using pixels and then the scale factor.

[scarlehoff]

I see. Well, I’ll have a look at it when/if I have the time since for me it would be a nice feature to have.
If it turs out to be too difficult I’ll just stop using Thunderbird :__

[emersion]

KDE is working on a better solution: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/111

It still requires some compositor changes, but limited to the X11 WM, which makes it a lot better than the Mutter solution.

[rtsisyk]

Any news? Sway is still completely unusable for me because all X11 applications are blurry. GNOME works well.

[akvadrako]

I have a workaround here: https://github.com/akvadrako/sommelier

It runs a nested Wayland compositor that presents unscaled pixels to a new XWayland instance. Programs run under this X session look sharp.

[tokyovigilante]

I have a workaround here: https://github.com/akvadrako/sommelier

It runs a nested Wayland compositor that presents unscaled pixels to a new XWayland instance. Programs run under this X session look sharp.

@akvadrako This looks really promising, as I just want to run my web browser under XWayland and all my other apps are native, however I get the following error when trying your fork:

[Thu  7:47PM] ryan@crackotage ~/$ GDK_BACKEND=x11 GDK_SCALE=2 sommelier -X --scale=2 vivaldi
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
Errors from xkbcomp are not fatal to the X server
Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
[5137:5137:1205/194805.346246:ERROR:chrome_content_client.cc(343)] Failed to locate and load the component updated flash plugin.
[5137:5331:1205/194805.458030:ERROR:database.cc(1581)] Calendar sqlite error 1, errno 0: no such column: etag, sql: update events set etag = ''
[5137:5331:1205/194805.458042:ERROR:calendar_database.cc(47)] Calendar DB failed to migrate from version 1. Calendar API will be disabled.
[5200:5200:1205/194805.463541:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[5137:5331:1205/194805.471887:ERROR:calendar_backend.cc(152)] INIT_TOO_NEW
sommelier: ../sommelier.c:667: sl_window_update: Assertion `ctx->xdg_shell' failed.
[5137:5137:1205/194806.032177:ERROR:CONSOLE(0)] "Unchecked runtime.lastError: The message port closed before a response was received.", source: chrome-extension://mpognobbkildjkofajifpdfhcoklimli/browser.html (0)
Aborted (core dumped)
(EE) failed to write to XWayland fd: Broken pipe
[Thu  7:48PM] ryan@crackotage ~/$ [5137:5137:1205/194806.051121:ERROR:chrome_browser_main_extra_parts_x11.cc(62)] X IO error received (X server probably went away)
[5200:5341:1205/194806.051122:ERROR:x11_util.cc(110)] X IO error received (X server probably went away)

[akvadrako]

sommelier: ../sommelier.c:667: sl_window_update: Assertion `ctx->xdg_shell' failed.
[5137:5137:1205/194806.032177:ERROR:CONSOLE(0)] "Unchecked runtime.lastError: The message port closed before a response was received.", source: chrome-extension://mpognobbkildjkofajifpdfhcoklimli/browser.html (0)
Aborted (core dumped)
(EE) failed to write to XWayland fd: Broken pipe
[Thu 7:48PM] ryan@crackotage ~/$ [5137:5137:1205/194806.051121:ERROR:chrome_browser_main_extra_parts_x11.cc(62)] X IO error received (X server probably went away)
[5200:5341:1205/194806.051122:ERROR:x11_util.cc(110)] X IO error received (X server probably went away)

Good to know. Indeed it seems like an unfinished project. It does work for some apps, but for example VSCode also randomly crashes. If you would make a bug report in the repo, that’s a better place to discuss. I might find the time to investigate myself.