Wayland 1.22 Released With New Preferred Buffer Scale & Transform Protocol

[dragorth]

Oh right. Setting a custom scale to each window seems like an awkward workflow.

During lockdown and screenshare, I used to use Xephyr with custom scaling in each server for streaming at more friendly sizes. That could be adapted to per-application.

It could allow for some custom app workflows, such as in focus windows zooming in to one scale while background windows zoom out.

I wonder if it makes sense for games to use dual windows, one for the game itself and a second over top for a UI overlay. Most UI in games is designed for one aspect ratio, so this works fine, if it would be performant. Probably would be awkward in the code, however.

[rmfx]

It's so painful to see how slow this tech is progressing.

maybe in 10 years we will have it full featured ?

[You-]

It's so painful to see how slow this tech is progressing.

maybe in 10 years we will have it full featured ?

Which problems do you think are too slow? Any specific features?

As for when it will be "fully featured" will probably be the day after everyone has stopped using it - until new features and use cases will be found and implemented.

[kiffmet]

I currently have working fractional scaling in single and mixed-DPI multi-monitor scenarios with these settings on KDE Wayland. Wall of text incoming!!
Main monitor is a 123DPI 1440p 24'' monitor, the secondary one a 24'' 1080p one (has 92 physical DPI but the default value of 96 is fine).

Needed are: An executable bash script: ~/.config/plasma-workspace/env/wayland_dpi.sh:
That script sets the session-wide env variables, that make QT programs and LibreOffice scale properly, at login.

#!/bin/bash
[ "$XDG_SESSION_TYPE" == "wayland" ]  && export QT_WAYLAND_FORCE_DPI=123 && export SAL_FORCEDPI=123

Then there are several config files for XWayland and GTK apps:
~/.config/xsettingsd/xsettingsd.conf - this needs to contain at least:

Gdk/WindowScalingFactor 1
Xft/DPI 125952
Gdk/UnscaledDPI 125952

with the DPI values entered being "primary monitor's physical DPI" * 1024

~/.config/GTK-3.0/settings.ini
~/.config/GTK-4.0/settings.ini

gtk-xft-dpi=125952
gdk-unscaled-dpi=125952

These 3 config files need to be made immutable (sudo chattr +i file) after setting the values, such that kde-gtk-config cannot override them!

Additionally, using gsettings or dconf-editor, org.gnome.desktop.interface.text-scaling-factor has to be set to 1.28125 (how much drawing on the hiDPI screen needs to be enlarged in relation to the other one, here calculated as 123DPI / 96DPI. The KDE fonts KCM is left untouched and the second screen is set to 75% scaling in Kscreen (on this monitor, elements will retain their default ~96DPI size, since it's 75% of the now 123 DPI!).

For me, this yields a sharp primary screen without scaling artifacts (since it isn't scaled, instead everything is drawn bigger from the get-go!), a slightly blurry secondary screen (although by no means unusable, text is still perfectly readable), windows, text AND icons scale and have the same physical size on both screens.

All applications, be it Xwayland/Wayland, GTK/Qt/Electron do scale (with the exceptions of Steam and Chromium; the former can only do integers, the latter will do automatic UI scaling by forcing the ozone-platform to X11) and no applications receive scaling twice (like it can happen for Xwayland GTK apps in other approaches).

The part with the xsettingsd and GTK config files, aswell as the gsettings thing weren't needed until recently, since the GDK_DPI_SCALE envvar is deprecated and being phased out.

In case you have issues/draw size mismatch between the screens:

It would probably be better to set the primary monitor DPI and thus scale factor not to its physical dimensions but rather in a way that 96*scale_factor*0.75 = physical DPI of the 2nd monitor. Here, this condition was met by chance, and that's likely what lead to the window sizes working out perfectly.

I do honestly wish that in the future I can just set a per-screen DPI (no % sliders!) in Kscreen, without touching the global font DPI, and have it automatically figure out these values, or, where available, just use the native capabilities of the toolkits to draw bigger instead of rescaling the output…

Just FYI, the alternative of just setting the primary screen to 1.25x in Kscreen doesn't look good at all, and messes up font rendering, and causes physical size-mismatch between elements on both screens, so it isn't an option at all for me…

Needless to say, finding out how to impose my will on the toolkits and working against the designs of their devs was a real hassle, but in the end, it totally paid off, since that config now is 95% close to being perfect (with 100% being non-blurry 2nd screen). Anyhow, I hope these findings can be helpful for someone.

[jarekZ]

It's so painful to see how slow this tech is progressing.

maybe in 10 years we will have it full featured ?

this is free software. Contributions are welcome I guess

[Quackdoc]

this is free software. Contributions are welcome I guess

I can think of a couple better investments, I think keeping money in my bank account has a higher return rate then wayland does xD

[Barnacle]

Which problems do you think are too slow? Any specific features?

The problems are the the design of Wayland making uptake nearly impossible. If they could have kept it somewhat inline with the way existing display servers work, maybe it wouldn't take decades of work for the downstream developers to implement. It's not as if there is any real advantage to using Wayland to justify everything you are giving up to use Wayland.

[Barnacle]

this is free software. Contributions are welcome I guess

It's easy to say that, but if let's say I'm feeling generous and decide to fix the "feature" where they pop up windows on random parts of the screen to "shame" developers for coding practices that don't do that on X11, Windows and Mac, then they are going to reject the pull request. Which means the only option is to fork it or create a new display server.

[You-]

The problems are the the design of Wayland making uptake nearly impossible. If they could have kept it somewhat inline with the way existing display servers work, maybe it wouldn't take decades of work for the downstream developers to implement. It's not as if there is any real advantage to using Wayland to justify everything you are giving up to use Wayland.

What are you giving up?

For me Wayland has been complete for a long time.

The new fractional scale protocol I am a bit iffy about - if it works well, great. If it doesn't, I was happy with the downscale method already.

The new high dynamic range is something interesting, but so far very few people using linux have hdr capable displays.

Both of them however are above and beyond anything natively in x11.

The proposed protocol to ad screen tearing back into your life is one I am definitely against.

I don't know of any protocol or update that I am waiting for which adds a feature you would actually want and x11 implements.

Hence the question, what specifically are you waiting for?

[jarekZ]

It's easy to say that, but if let's say I'm feeling generous and decide to fix the "feature" where they pop up windows on random parts of the screen to "shame" developers for coding practices that don't do that on X11, Windows and Mac, then they are going to reject the pull request. Which means the only option is to fork it or create a new display server.

to make other people accept your contributions, you're supposed to discuss and coordinate your efforts with them.

So just for example. There's such merge request (in gitlab they call it merge, not pull requests) already: https://gitlab.freedesktop.org/wayla...ge_requests/28. So indeed, if you will generously come up with something new then it will be outright rejected.

The proposed protocol to ad screen tearing back into your life is one I am definitely against.

it can be turned on after your explicit consent only, so nothing to be worried about