PSA: XWayland doesn't have to be blurry on GNOME

[-]

CornFleke@reddit

Any reason why is it disable by default? I feel like if it was that well implemented and working it would had been enabled by default.

[-]

pol5xc@reddit

Because if you only use integer scaling you don't need it and you're better off with gsettings set org.gnome.mutter experimental-features "[]"

[-]

PDXPuma@reddit

As with all things in GNOME, they don't want to enable a setting until they know it works for everyone (or almost everyone.) As also is typical with this, the blocking point is almost always NVIDIA.

[-]

Zettinator@reddit

XWayland scaling is disabled by default because it is a hack and doesn't work properly in all applications.

X only has limited support for HiDPI and no support for fractional scaling (and probably never will have).

[-]

Existing-Tough-6517@reddit

High DPI works great on basically everything now. Do you live in a different universe than me?

[-]

Zettinator@reddit

We're talking about the native XWayland HiDPI scaling feature which tries to avoid blurry upscaled XWayland windows when you have more than 100% scaling.

As far as native Wayland HiDPI and fractional scaling is concerned, everything is pretty much perfect nowadays, yeah.

[-]

Existing-Tough-6517@reddit

To be clear this is typed on a high DPI monitor with X, everything works here too.

X only has limited support for HiDPI

Appears to be imaginary. It appears to judge X high DPI support by how xwayland apps work on gnome.

[-]

X doesn't support mixed-DPI setups (e.g. with multiple screens at different scale factors), doesn't support fractional scaling, and on top of that application support is limited and there is no graceful fallback for apps/toolkits that do not respect the HiDPI hints (so they render tiny). Maybe it works OK for your specific setup and the subset of application that you use, but in general it's not a good experience.

[-]

Existing-Tough-6517@reddit

You said X doesn't support high DPI not mixed DPI. Yet all common toolkits support integer scaling under X which works fine on the overwhelming majority of high DPI display hardware. EG 12-15" 1080p laptops and 24-28" 4K monitors. Which are shockingly around exactly 2x the standard DPI that has been common for so many years. This isn't by accident. I know math hard.

There are no such thing as "HDPI hints" in this context as that isn't a term that means anything here. This most common and simple configuration is a env variable in your profile like GDK_SCALE=2.

There are no common toolkits that don't support HiDPI under X at this point. You literally set a few variables and use your computer like normal as all your apps look normal. If everything is high DPI you are done. No work needed.

If you have high and standard DPI you can set a per monitor scale factor with xrandr nvidia-settings or cinnamon-settings. The way this works with nvidia settings or xrandr --scale is you render all monitors at high DPI and scale down to actual physical resolution.

Because X is handling the only scaling no apps have to do ANYTHING to support this. They don't have to react to being moved between monitors. They don't have to scale themselves intelligently or respond to different "hints" they literally just have to support high DPI.

The result isn't buggy, doesn't work with some apps and not others, isn't blurry.

All these problems are basically gnome. You've been able to have high DPI + X for like literally 10 years or more.

Basically gnome developers live an an alternative universe.

[-]

Zettinator@reddit

Mixed DPI and high DPI is kind of the same thing to me as mixed DPI setups are very common in practice. If you have e.g. a high DPI laptop screen and low DPI external display, which is pretty typical, you already need ability to handle mixed DPI setups.

There are no such thing as "HDPI hints" in this context as that isn't a term that means anything here.

Well, the classic way are Xft or Xrandr DPI settings, but you are kind of right - there is no totally standard way to handle this. The DPI setting is usually ignored. And this is part of the problem. The common toolkits, depending on version, use different methods to configure a scale factor, for instance via environment variables. Every toolkit needs special configuration and sometimes applications need specific overrides. Legacy applications and toolkits often do not support scale factors at all, so they will render tiny. And in the end, it's all very static, if you switch from a low DPI to high DPI display at runtime, or vice versa, the scale factor won't adapt.

I really have no idea how you can come to the conclusion that things are just perfect the way it is on X. It's an unusable clusterfuck! Maybe you are used to this at this point, but it sounds more like some kind of stockholm syndrome. :)

If you have high and standard DPI you can set a per monitor scale factor with xrandr nvidia-settings or cinnamon-settings

Which is a major hack. It is very inefficient and slow in many scenarios, for instance. It also causes tearing with many GPU drivers.

The sorry state of "hacks on top of hacks" is precisely why X development was abandoned in favor of Wayland.

[-]

Existing-Tough-6517@reddit

Mixed DPI and high DPI is kind of the same thing to me

Literally not

Every toolkit needs special configuration

This takes 5 minutes for a machine you can then use for 5 years

Legacy applications and toolkits often do not support scale factors at all, so they will invariably render tiny

Such apps are basically non-existent in practice.

if you switch from a low DPI to high DPI display at runtime, or vice versa, the scale factor won't adapt.

xrandr supports scaling the display not the app. This means apps moved from display A -> B will in fact be scaled correctly on each screen. Thinking it as the app scaling is exactly the wrong way around. In the example with a 4K and 1080p monitor from the apps perspective there are 2 4K screens and the scale factor is constant. Only X sees the need to scale all the pixels on the lower DPI screen down to the lower physical DPI. note pixels not apps. The apps can be stupid as you please because all they are being asked to do is support integer scaling.

Only once you go over the hill to Wayland land do we require the apps to care or know about scaling. Whereas in X land we can rely purely on scaling the display NOW we have to be smart or look wrong.

You are once again confusing gnome/X with what X can do. Which is truly hilarious because people running window managers have had a better experience than gnome since inception because X can do more than is exposed by gnome display settings.

Both high and mixed DPI as you mentioned are more common and xwayland being so bad when combined with it has basically made gnome useless to anyone who must simultaneously rely on apps which in turn must rely on xwayland.

Wayland proponents simultaneously crow about having better support whilst having when relying on xwayland MUCH worse support than someone running a window manager from 2010.

[-]

mort96@reddit (OP)

From what I understand, to support fractional scaling, Mutter will (with the experimental features enabled) tell X applications to render at the closest integer scale that's greater than or equal to your fractional scale, then downscale. So at 150% scale, it'll render at 200% and downscale.

That's how a lot of Wayland compositors have done fractional scaling too. Protocol support for fractional scaling in Wayland is actually rather new.

[-]

Zettinator@reddit

The problem with X HiDPI is that there is just a single global flag. So if you enable it, all applications that support the flag with always render at 200% and will be downscaled as needed. There is no way to dynamically change the scaling, so you're always going to significantly waste resources. And applications that do not support the HiDPI flag will render incorrectly.

Wayland had much better HiDPI support from the get go. It's true that true fractional scaling support took its time.

[-]

CrazyKilla15@reddit

That seems like a limitation purely on (x)waylands side. Wayland compositors using XWayland also serve as X window managers and run the XWayland server, seems to me they can control this.

Is there some rule saying there "has" to be a global flag and (x)wayland cant "lie" to apps just like it does with xrandr?(because under (X)Wayland obviously apps have no direct ability to change screen resolution and the like)

Or multiple xwaylands, one per unique scaling setting. Do all xwayland apps really need direct X access with each other?

[-]

MrHighStreetRoad@reddit

even with xwayland, there is still one instance of X. You could change the X protocol to fix this, I guess, and while you're there, fix a few other things... oh, wait.

[-]

CrazyKilla15@reddit

What do you mean? XWayland is the X server. XWayland functions as the X server, and it is entirely possible to run multiple instances of XWayland/X11?

Wayland desktops are also perfectly capable of passing applications(perhaps determined by .desktop files) different DISPLAY variables, and thus different xwayland servers?

[-]

MrHighStreetRoad@reddit

it is possible to have multiple xorg servers although whether any mainstream wayland compositor supports that is above my pay grade, and I've never heard of as a part of mainstream desktop as far as I know. I believe you lose things like clipboard sharing. Also, it does won't dynamically adjust if you move the app window to a monitor with a different scaling factor. The scaling factor is as far as I know a property of launch monitor, so my mucking around shows.

All problems can be fixed, even if it would be a massive overkill to solve the scaling problem. But the thing is, it has already been fixed, scaling and so have many other X problems. The KDE "solution", which Gnome has adopted, sounds like simply changing a default, a pretty low cost solution for which not so much new functionality as altered functionality, that may be helpful if all the X apps you still use can manage their own scaling. Such apps are a bit more modern and sophisticated than older X apps that don't have this capability, but you're then in this strange world of having functionality for apps that are modern enough to support their own HiDPI scaling but not modern enough to yet be ported to native wayland support. That must be a shrinking set of applications.

There is only one app family that would interest me for this, which is the JetBrains IDEs, but they have working wayland support now which illustrates just how niche this fix probably is.

[-]

CrazyKilla15@reddit

it is possible to have multiple xorg servers although whether any mainstream wayland compositor supports that is above my pay grade, and I've never heard of as a part of mainstream desktop as far as I know.

Yes, i was giving an idea of what current wayland compositor could do to improve xorg scaling, as something entirely within the realm of current technical possibility without having to rewrite or massively refactor xorg, something that plausibly works today and to which all the pieces already exist and work.

I believe you lose things like clipboard sharing

There is no technical reason for this to be the case. Wayland compositors already share the clipboard with their XWayland instance, if they supported multiple XWayland instances as I suggest I see no reason they cant share to them all, exactly like they already do.

Also, it won't dynamically adjust if you move the app window to a monitor with a different scaling factor, no matter how many x servers you run. The scaling factor is as far as I know a property of launch monitor, so my mucking around shows.

The suggestion is not mean to be "The Literal Perfect Solution To All X Scaling Issues Ever In The History Of Linux" it is meant to be "a substantial improvement to the status quo for relatively low effort". X not being able to dynamically adjust when moving monitors is not a problem unique to XWayland, single or multiple instances. I dont know why you think this is something to bring up here, its entirely irrelevant.

Scaling with XWayland is bad today, thats with this post and this thread are about, and As the comment I was replying to stated, has issues with being global to every X app, wasting resources for apps that look fine without scaling, some X apps look worse when scaled or otherwise render incorrectly, etc.

Those are problems that go away if it, as I suggest, it becomes possible to tell one X app, running via XWayland, to have scaling, and another to not have scaling. It would improve the situation as it exists today, without requiring massive new features in either xorg or wayland. I do not understand what is so difficult to comprehend about this.

It does not change the situation with per-monitor scaling at all and isnt meant to because thats an entirely unrelated and separate problem that would require a huge refactor of xorg to fix.

[-]

tesfabpel@reddit

but how do you assign windows to the correct instance of XWayland? and what if you move windows between screens?

[-]

CrazyKilla15@reddit

but how do you assign windows to the correct instance of XWayland?

Thats the (X)Wayland compositors job. The (X)Wayland compositor knows what scaling the user configured for a specific app, and knows what the default is if unconfigured. The point is so that if some apps look fine, or even break, at non-default scales, they can be configured to be default while others are 200%, for example.

and what if you move windows between screens?

Dont know what that has to do with things. Probably something no worse than whatever happens today to scaled XWayland windows moved between screens, due to limitations in X and its support for scaling?

[-]

spacelama@reddit

No support for fractional scaling? What have I been using for the past 15 years via xrandr then?

[-]

gmes78@reddit

What have I been using for the past 15 years via xrandr --dpi and --scale (and --filter nearest if you require

That just changes the internal resolution of each monitor, which is then scaled. It's not proper fractional scaling.

and -r to rebut the usual claim that x11 can't do independent refresh rates

That's not accurate.

[-]

gmes78@reddit

That's not accurate. GNOME does scale X11 apps by default, that's why they're blurry.

This is about an alternative method of doing said scaling.

[-]

Zettinator@reddit

Yes, of course, I guess I should have said XWayland HiDPI scaling. That would have been more accurate.

[-]

Qweedo420@reddit

Cosmic exposes these settings in the menu, you can check the difference there but the gist of it is that you either scale the app and it will look blurry, or you don't scale the app and it will look small on HiDPI screens

I'll take small over blurry any day of the week

[-]

Existing-Tough-6517@reddit

I still use X and its neither small nor blurry

[-]

Qweedo420@reddit

I suppose you're not using fractional scaling

[-]

Existing-Tough-6517@reddit

I'm using integer scaling factors for GTK/QT/Java etc apps but previously I have adjusted different sized monitors with xrandr --scale so as to have a 24" 1080p be identically scaled as a 28" 4K eg the 1080p was scaled up by 1.75x then downscaled to physical resolution.

I did not perceive this to make the 1080p blurry. I've been using xrandr --scale without perceptible blur early as the 2010s. This blurry mess seems to be a gnome specific stupidity with xwayland which they fantasize has to do with X rather than their implimentation of xwayland.

[-]

Fiftybottles@reddit

In my experience it has issues with misaligned mouse clicks and overly-tiny windows + titlebars (as in, smaller than even an unscaled window) on all my machines. Maybe some are just more lucky than I am or it's better on Gnome 48 now, but it hasn't worked properly across three laptops for me which is probably a decent reason for it to stay experimental for the time being.

[-]

mort96@reddit (OP)

What apps were this in, if you don't mind sharing?

I haven't used this a lot since I just found out about it, but with my setup (one 100% scale 1920x1200 secondary monitor to the left, one 150% scale 4k primary monitor to the right), at least LMMS, Signal, Steam and Spotify seem to be working about as well as if they had been native Wayland apps. Mouse clicks happen where I expect, title bars look normal, nothing is too small (except Steam before I enabled that high DPI setting, but that would've happened in X as well).

[-]

FattyDrake@reddit

Darktable has issues too if you have different scaling on multiple monitors.

[-]

Fiftybottles@reddit

It happened in Steam and Spotify for me, as well as various games having some weirdness when using a mouse in their UI in general. It also happened a lot in Discord, and generally anything Electron that wasn't using the native Wayland platform. It's been awhile since I've tried it so maybe I'll give it another go.

[-]

Existing-Tough-6517@reddit

Its not a very good desktop and they are bad at what they do.

[-]

mort96@reddit (OP)

I don't know their rationale for it, but I feel like GNOME keeps things "implemented, but experimental" for longer than necessary. Fractional scaling was also "experimental" for a long time after it was implemented and (in my experience) perfectly functional. Maybe they don't feel like it has been tested on a wide enough variety of hardware and setups yet.

If more people enable this, we can get more attention to it, which might help get it out of the experimental phase. Especially if people report any issues they experience.

[-]

callcifer@reddit

It was and is experimental because it has known bugs. That you don't happen to encounter them doesn't mean it should be enabled by default.

[-]

CrazyKilla15@reddit

GNOME as a whole should be marked experimental then. GNOME, and all large software, have non-zero amounts of "known bugs", after all.

If it works in the majority of cases and significantly improves the user experience, it should probably be on by default even in the presence of known bugs, especially if the workaround until the bugs can be fixed is "just turn it off and you're no worse than before it was enabled-by-default"

[-]

callcifer@reddit

If it works in the majority of cases

How do you know that?

[-]

CrazyKilla15@reddit

       VV this word

this here --> if <-- this here

       ^^ this word

[-]

Urworstnit3m3r@reddit

Because it causes issues for multi monitor. for example if I enable that on my triple monitor setup, games now do not realize the mouse only belongs to them so when you turn the camera with the mouse, the mouse ends up on your other monitors.

[-]

Misicks0349@reddit

I think with these features GNOME tends to have an abundance of caution when implementing them, and makes a lot of stuff experimental until it works for most users by default.

[-]

Patient_Sink@reddit

It can be wonky with games in fullscreen or multi monitor setups iirc, and probably other edge cases right now.

[-]

TopCheddar27@reddit

I always just assume that it's more of a time thing to let bugs propagate, so that the "average" user doesn't get a bad taste.

Same thing for VRR, I find it to work pretty well. But it's still hidden behind the same thing.

[-]

ABotelho23@reddit

It's so rare to have serious bugs in supported GNOME settings. It's not for nothing.

[-]

JockstrapCummies@reddit

PSA: If you're on Ubuntu 25.04, turning on fractional scaling in system settings already enables these two experimental features in Gnome.

[-]

linuxjohn1982@reddit

I'll switch to Wayland when SteamOS does. As a Linux gamer, this seems like the way to gauge whether Wayland is ready.

[-]

InfiniteSheepherder1@reddit

Aa far as i know gamescope is Wayland based compositor and then using xwayland to talk to games.

So it is already using Wayland

[-]

nonesense_user@reddit

Steam has an internal HiDPI-Mode for some time. Turn it on :)

IntelliJ also but you should use their own internal JRE. Java shouldn’t be used on Desktop - the idea of a GUI-Toolkit in a language-library is and was a mistake[1]. But when you need to use a Java, avoiding a Java-IDE is hard. AWT, Swing, JavaFX…I cannot say which one is worse. All?

[1] Use the native toolkit!

[-]

gmes78@reddit

IntelliJ also but you should use their own internal JRE. Java shouldn’t be used on Desktop - the idea of a GUI-Toolkit in a language-library is and was a mistake[1]. But when you need to use a Java, avoiding a Java-IDE is hard. AWT, Swing, JavaFX…I cannot say which one is worse. All?

It also has a native Wayland mode now, so there's no need for that.

[-]

nonesense_user@reddit

For that mode the internal JRE is required :)

[-]

gmes78@reddit

For that mode the internal JRE is required

Newer versions of Java have some level of support for Wayland in its graphical toolkit built-in. I use the default OpenJDK instead of JetBrains's JRE, and it works mostly fine.

[-]

Misicks0349@reddit

still waiting for the steam client to run on wayland natively dammit :P

[-]

spazturtle@reddit

Not going to happen until Wayland adds a global positioning API.

[-]

Misicks0349@reddit

I don't see why the steam client would need that, its basically just a chrome frontend.

[-]

spazturtle@reddit

Because Wine/Proton needs (for non-fullscreen apps). And the Steam client is always the last to get upgraded, just like how it is still 32bit on Win and Linux.

[-]

Misicks0349@reddit

I don't see why wine would be a blocker considering that the steam client itself its not built using wine, a version of the client running under wayland would be able to launch Xwayland wine apps perfectly fine.

[-]

FrazzledHack@reddit

Java shouldn’t be used on Desktop - the idea of a GUI-Toolkit in a language-library is and was a mistake

What is a language-library? Swing is included in the standard Java libraries, but it's not a feature of the Java language.

Use the native toolkit!

Java is cross platform. There is no native toolkit.

[-]

gianfrixmg@reddit

I have an external display (100% scaling) which I use as a primary display, connected to my laptop (125% scaling). If I set that flag on GNOME or use the default "let apps do the scaling" setting, text is blurry on the 100% display, like it's scaled down from 125%.

Thus, I prefer using Wayland mode on apps that support them well, like Chrome, that I happly use on my laptop display.

[-]

ManuaL46@reddit

Yes mixed DPI is not really usable with xwayland apps, even on KDE this issue exists.

[-]

ManuaL46@reddit

Well mixed DPI will still have blurriness/weird, doesn't matter if you're on gnome or KDE.

I just hope steam and proton will embrace wayland...

[-]

MrHighStreetRoad@reddit

"since KDE has had this fix implemented and enabled by default for ages now"

Now, can we talk about touchpad scrolling speed control ...

[-]

LaserWingUSA@reddit

I did this the other day on my bazzite install, and it really saved me from ditching my attempt at returning to a Linux distribution. I was a GNOME foundation member back in the day and I’m glad I stayed long enough to figure out this solution because they really have made a nice looking desktop environment otherwise

[-]

GOKOP@reddit

Another PSA: as long as you're not using different scales on different monitors, you can get most X11 apps to be scaled properly too in some environments at least. Don't know how to do it on GNOME though

I'm using Hyprland and to do that I'm setting DPI corresponding to my desired scale (96 = 1) in .Xresources. (Xft.dpi: <number>)

This is a general method for any environment where that value isn't somehow overridden or ignored. Unfortunately it seemed to have no effect on GNOME last time I tried

[-]

BortGreen@reddit

Unfortunately I'm stuck to Ubuntu LTS so no way to do it for now