KDE Lands Wayland Fractional Scaling Support

[Azrael5]

As far as me, Kde Neon is not usable under Wayland if an Nvidia card run although Mesa drivers. The system freezes almost immediately on Nvidia 7xx GPu.
Meanwhile, I don't know how Nvidia proprietary drivers are evolving to match Wayland.

[Sho_]

Where does that info come from? The only thing I can find on it is GNOME devs refusing to do anything about since it requires too much internal rework and might result in API breakage (for no clear reason).

https://gitlab.gnome.org/GNOME/gtk/-/issues/4345

As mentioned in a later comment, I was basing it on Nate's blog + I saw an implementation of the compositor side being submitted for Mutter, which together made me optimistic since it seems so entirely sensible to support this. I wasn't aware of that GTK ticket you linked and it leaves me quite surprised how dismissive and negative the convo there is. Sorry about the misinfo.

[Sho_]

Speaking personally, this seems like a solid enumation of what could be provided as user-configurable options. I don't know if the effort to do so would be worth it vs. spending the effort on fixing the apps though, since fixing the apps would always produce the best visual result and more options have an ongoing maintenance burden. There's a cut-off there, and where to draw the line (given finite resources to do stuff) depends on complex predictions of the effort needed to fix the apps or how likely it is users will stick to apps not sufficiently maintained to fix this (since those apps will likely also fall behind the times in other ways and lose favor). You can spend a lot of effort on options that only remain useful for so long, and some decisions can also artificially prolong a state of affairs in the ecosystem.

I wouldn't be surprised if e.g. KWin adds some more options down the line to configure behavior per-window or per-app (since it already has a Window Rules infra in place), but I'll predict most compositor devs will prefer to leave it at "we now have infra for apps to do all the right things; apps, please do so".

These kinds of decisions (how far to take backward compatibility) are always among the hardest for devs and users also fall on different sides of the issue in terms of where they would prefer devs spend their resources. I'd say Linux tends to fall inbetween MacOS and Windows there usually, with MacOS rather brutally killing older APIs and behaviors and expecting app developers to go with the times, and Windows maximizing on backward compat.

[Quackdoc]

the only OS with good scaling is android xD.

but the big thing is the compositor being able to just render at native. it doesn't matter to me what apps that don't scale do, they can ignore it, they can be upscaled, or 2x scale and downscale, it matters not to me. and I figure most people typically won't care either. for me, it's as simple as avoiding GTK apps like the plague that they are, im just worried how waydroid is gonna fair with this, but thats something that can be figured out.

[billyswong]

This is area where I think we just need per application controls. With controls providing the following options
1) Do not ask this application to fractional scale because it fractional scale implementation is busted.
2) Do not ask this application to interger scale because it integer scale implementation is busted.
3) Method option for compositor side integer upscale.
4) Method option for compositor side fractional scale.
5) Freetype overrides(force hinting on and off and so on)
Yes all these controls as .desktop entries.

I think some compositor may not want to implement choice 1 and choice 2, as they are bug mitigation scheme for misbehaving software. But 3 and 4 do matter. Some software graphics favour antialiasing while some favour jaggish pixels. There should be some way to combine choices for 3, 4, 5 into one list of scaling preference.

[billyswong]

I did, but all the crucial information is missing.

Can you point me to the first place where the word "Lanczos" is mentioned? Perhaps I have missed it.

Since the native fractional scaling support in Wayland is all about support of fractional scaling done by the application side, it is normal for no resampling / filtering algorithm mentioned in this news. How an application implement fractional scaling internally is offtopic.

[Sho_]

It's not that you're wrong, but I think it's reasonable to assume that the majority of applications use a toolkit where part of the toolkit's value prop is to make this easy on the developer, or are the type of application where scaling is relatively easy/natural to achieve because supporting variable target resolution is for example relevant to adapting to machine peformance (i.e., 3D games). Then the second assumption (and this is what lead me to frame it as a backwards compatibility issue) is that the number (or fraction) of apps which don't support scaling due to being legacy or unmaintained is larger than the number (or fraction) of modern apps that refuse to support scaling, and that those fall out of use over time or eventually do get fixed.

There may be some modern/maintained apps that refuse to do scaling, but then it begs the question whether spending effort on them is worth spending the required resources. I could totally understand if some compositor devs decided they must offer those options to have a full set of tools for dealing with all conceivable scenarios. It's also fine to argue for that. But I predict most teams will likely decide to aim for something different in terms of dev resource allocation.

Incidentally, the best use case I can come up for this is in fact games you can't afford to render at hi-dpi resolutions and then want to upsample as a compromise. For a gaming-optimized compositor (e.g. gamescope, which you can nest) it'd not be a bad thing to support. Nesting compositors and making that low-overhead is also a valid path to pursue here in terms of how to compose a solution to the overall problem. gamescope also supports exotic HW-accelerated scaling stuff like nVidia's image scaling and AMD Super Resolution that outperform basic Lanczos for this type of window content. Game consoles today also tend to do dynamic res scaling where the game drops resolution situationally and upsampling is used temporarily to account for it without having to switch video modes.

Most desktop apps don't operate near the machine performance ceiling enough though to warrant that type of sophistication, and changing res+scaling dynamically is also more visually obvious in their type of content.

[Sho_]

It's certainly a possibility that thinking on this could evolve more in the future based on empirical data (e.g., the problematic apps prove more sticky than expected), yeah. Even then however it could be that postponing the effort is still the right call, if the freed-up dev resources are put to another good purpose in the meantime. That depends on what the success metric you optimize for is, and so on (and also keep in mind that to some extent that success metric is personal and individual to each contributor in most FOSS projects).

[Sho_]

Anyway, to get back of-topic....

Noone has provided any commentary on my original critique of Wayland in this thread (this post).

Since you were so nice to answer all of my questions so far (I really dislike walls of silence), and we got into the interesting discussion, I was wondering whether someone can provide me with some feedback on the issues that I have outlined about Wayland in that post.

I did see your post earlier and I did skim it, but at the time didn't have the time to read it and think about it in detail. I still don't have the time to engage thoroughly right now, but I can react to a few of your thoughts that I saw while skimming and could identify with. So take the below more as a loose sort of reply and picking my brain, not a refutation.

(a) In general, I would say the Wayland community's value judgement of keeping the core protocol small and relying heavily on extensions is a reaction to experience with X11, both good and bad. Many people felt that the core X11 protocol and Xorg reference implementation were just too large and that having a large core made it too hard to evolve. On the other hand, extensibilty through add-on protocols is also what made it possible to keep X alive and have it take on an expanding problem space for 20+ years. Another factor here is that creating Wayland itself was enabled by moving a lot of complexity from the X server into the Linux kernel, which further advocated for a more minimal approach.

X was also originally designed for a narrow application field (mainframe terminals) and only successfully expanded into one other (workstations), but by the time Wayland was created, there was a big interested in Linux graphics also for other kinds of systems.

Sum it all up, and you can see how the initial "minimal, but extensible" mindset came about.

(b) Part of that "minimal, but extensible" mindset was initially also follow-on ideas such as having purpose-optimized compositors and nesting compositors. For example, an initial assumption was that you would have a system compositor and nest session compositors below, and that the teams doing the latter should be free to make their own design decisions, including what protocols to support. In practice this hasn't materialized all that much, partly because compositor development I think turned out to be a bigger job than expected. That said, there's actually a recent resurrection of these ideas. See my earlier post about gamescope as an example. This is partially also down due to compositors consolidating on more shared support libraries, e.g. for input handling (often factored out of the Xorg server).

(c) In the early years, the "small, but extensible" mindset extended to Wayland governance being arguably also a bit hostile toward blessing extension protocols as official additions. It was preferred that the different compositor teams cook up their own extension protocols to solve their issues. This left an entire community of people who like to build their shell out of smaller components (e.g. the tiling WM + dmenu crowd, etc.) a bit underserved since they needed a standards venue in which to agree on interfaces, so a lot of people were a bit unhappy with wayland-protocols governance. I myself once worked on an XDC talk together with Drew DeVault from wlroots/sway to suggest a better governance model, although the talk proposal was rejected. Anyhow - fast forward a couple of years, and the governance model was in fact changed and overall it's a lot healthier now, and there has been a noticable uptick in protocol proposals coming from different groups being ratified and included. In KWin/Plasma we've actively pushed a few, and we're also giving up some of our older homebrew protocols in favor of more standardized ones (e.g. layer-shell). This governance change has been fairly key for promoting more interoperability.

(d) You wrote about adjunct protocols having some development overhead because they come with their own ways of doing auth or handshakes or init etc. Here I disagree somewhat; Wayland has a lot of accumulated best practices for what constitutes good protocol design, and combined with a good governance model for the core upstream and peer-review, these days new extension protocols generally do not offer surprises and are quick and pleasant to adopt. This wasn't always true in the early days; there is an earlier breed of extension protocols where things like transaction semantics were done in ways that are now considered quirky, and that have fallen out of favor. These have not ever really impacted desktop systems much however, it describes embedded stuff like ivi-shell and so on.

(e) There's still a kernel of truth in your statement however, as for a time the community also had trouble in agreeing what sort of DE features should be orchestrated through Wayland IPC, and which through other channels like D-Bus IPC. I commented on this myself in a blog post a few years back. Here also I would say best practices have been slowly emerging, but it's perhaps not fully resolved yet.

Generally speaking, overall I think the Wayland community has been maturing nicely, especially in the last 2-3 years. The way we build Wayland together has a more regular rhythm to it than it used to, there's less disagreement and faster progress. Things that I was once unhappy with have mostly been resolved. Hopefully we value the lessons and keep it up.

[Sho_]

FWIW, I replied to your post, but perhaps because it's a long reply it's apparently stuck "Unapproved" in a mod queue, so I guess we have to wait a while for it to pop in above. Rather annoying, also because I made a typo in it (mislettering bullets) and can't edit to fix.

Edit: Now I edited it with the fix and it has to be re-approved. Sorry, mod.