Having recently started using a laptop which has a high dpi display, I think I'd agree that this is one of the biggest issues that we face right now. Out of the box with the 200% default scaling, the experience felt very wrong. Switching to 100% wasn't great, either.

That's not to say that I don't recognise the challenges here. Having started using fractional scaling, fuzziness is a serious issue, and I find myself having to switch back to non-fractional scaling for some tasks and applications.

I've been using it for years now and find it fine, though I tend to run mostly 'good' apps. I only have a few 'unusual' ones which get the fuzzies.

I'm glad I'm not the only one now with HiDPI fractional scaling experience in the WG. Maybe now there will be some movement...

So I'm aware that some changes have landed recently. Perhaps the mutter maintainers could summarize here what has happened and what problems remain?

@aday, why is 200% treated as “fractional” anyway (albeit mathematically so)? It's surely just x2 the size.

I don't think it is. 200%, 300% etc. are referred to as "integer scaling" and are enabled out of the box already (they are used automatically on screens with a high-enough DPI). "Fractional scaling" is anything that's not integer scaling, and it is not yet enabled out of the box.

So I'm aware that some changes have landed recently. Perhaps the mutter maintainers could summarize here what has happened and what problems remain?

I don't want to pollute this issue, but this is the most recent comment I've seen with regards to fractional scaling:

Emmanuele Bassi / @ebassi
https://gitlab.gnome.org/GNOME/gtk/-/issues/4345#note_1606121

This comment suggests it won't be available until GTK5 at the earliest:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143#note_1344788

Here's a commit for Mutter:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394

OK, so we have a GTK-side problem here too? Lovely. So far I thought this was just a mutter problem. :(

After https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394 is there anything more remaining to be done on the mutter side? Sure looks like that's what users have been requesting?

I mean, I don't know what "GTK4 only has integer scaling, no expectation for this to change until at least GTK5" means in practice. I'm using fractional scaling on Fedora 38 right now to type this message (this Firefox window is on a 32" 4K monitor set to 125% scaling) and as far as my eyes can see it works fine.

I know this is a complex area and I do still run into the occasional app that looks fuzzy on my fractional-scaling display, but as I said, I've been using fractional scaling in production every day for years and it works well enough for me anyway.

Firefox is not a GTK app. What happens with an actual GTK app...?

What setting do you use to configure the fractional scaling?

Anybody know why users are complaining about fractional scaling if it works well enough for Adam?

A recent reply to this post by Jonas Åhdahl explains the current state of fractional scaling in GNOME using the experimental setting here

https://discourse.gnome.org/t/full-explanation-of-current-hidpi-fractional-and-integer-scaling-support-in-wayland/14225/2

From what I understand Wayland applications will scale correctly, but X11 doesn't which is why we see the blurry fonts.

What setting do you use to configure the fractional scaling?

Per https://wiki.archlinux.org/title/HiDPI

Wayland
$ gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Xorg
$ gsettings set org.gnome.mutter experimental-features "['x11-randr-fractional-scaling']"

Anybody know why users are complaining about fractional scaling if it works well enough for Adam?

It could depend on the resolution and monitor size and whether or not the users are using apps that don't scale correctly or not. If you're using a music player then you won't really notice it that much since these are often in the background. As with everything some will be more sensitive to the blurriness than others.

Yes, that setting.

Next to the Firefox window is an Evolution window. It works fine. Behind that is a gedit window. It works fine. Floating around all of them is a GNOME Terminal window. It works fine. (You may be sensing a theme here). I have a Quaternion (qt app) window too. Works fine. When I say it works fine I don't mean it's blurry but I can live with it, I mean it looks fine, as good as if I was using integer scaling. Here's a screenshot. This whole screen is at 125% scaling, set in Displays after toggling the scale-monitor-framebuffer thing so the setting appears.

As @nado-x says, I think the only apps that get blurry are X-native ones. The only one I personally run into semi-regularly is hexchat, if I need to log in to IRC for some reason.

We've also been tap-dancing around the fact that this is possibly unfixable. While some X11 apps are HiDPi aware and will do their own thing if given the opportunity to, most don't.

I think that that Emmanuele's comments about GTK 5 are irrelevant because they don't fix anything for users today or tomorrow. GTK 5 is far away, and at this point I'm not sure what the motivations are for holding back the toggle for a feature that has existed for at least half a decade now.

It's a major competitive issue since Ubuntu patches in the ability to use the feature, and KDE Plasma has offered it for a while now too. It makes Fedora look bad for not being able to handle the "basic" thing of scaling properly for these screens.

So Ubuntu exposes this same setting and accepts that XWayland apps will be blurry? I'm 100% OK with that because XWayland apps are legacy and it's OK for the user experience to be degraded there, assuming that happens on other distros too.

Does kwin have the same blurriness problem? What does KDE do?

So Ubuntu exposes this same setting and accepts that XWayland apps will be blurry? I'm 100% OK with that because XWayland apps are legacy and it's OK for the user experience to be degraded there, assuming that happens on other distros too.

Does kwin have the same blurriness problem? What does KDE do?

As long as there is the option to toggle it on/off, I think the option should be available for the user. The next question is if it should be on by default? The preinstalled apps support Wayland so it would make sense to enable the setting by default - it will give new Fedora users a better out of the box experience.

So Ubuntu exposes this same setting and accepts that XWayland apps will be blurry? I'm 100% OK with that because XWayland apps are legacy and it's OK for the user experience to be degraded there, assuming that happens on other distros too.

Yes.

Does kwin have the same blurriness problem? What does KDE do?

We offer the ability for apps to indicate they're HiDPI aware and let them handle scaling. Otherwise we scale them the same way.

Actually, I'm slightly wrong about kwin:

@zzag, is it possible to do a combination of the two modes for XWayland apps?

OK, so we have a GTK-side problem here too? Lovely. So far I thought this was just a mutter problem. :(

Far too much commenting here, and much too little knowledge.

Terms like 'fractional scaling' and 'triple buffering' take on mythical qualities in the fan base.

We can discuss the technical nuances of various implementation choices forever, but at the
end of the day the question for the working group is: do we want to enable the feature that
exists today in mutter, and live with the tradeoffs it implies for legacy X11 applications.

OK, so we have a GTK-side problem here too? Lovely. So far I thought this was just a mutter problem. :(

Far too much commenting here, and much too little knowledge.

Sorry if I've commented too much here with much too little knowledge, but I believe the mentioned benefits would satisfy the needs of many users who have been asking for better scaling.

Terms like 'fractional scaling' and 'triple buffering' take on mythical qualities in the fan base.

I can agree that the implementations aren't perfect, but don't they solve more problems than they create?

@mclasen for me these are rather different cases. Triple buffering is just a 'polish' thing. Fractional scaling is kind of...necessary, though.

Both my current laptop's internal display and this external monitor need fractional scaling to look good. At 100% everything's too tiny. At 200% everything's way too big. Without the feature my only choices are to use the old font DPI setting (which certainly doesn't handle everything), try and set large font sizes for everything (which is a pain to do and also doesn't cover everything), or run them at lower than their native resolution (which makes everything fuzzy). I just don't have another choice.

Neither piece of hardware is unusual. 32" 4K monitors are pretty common and cheap these days. The laptop is this year's Dell XPS 13, which is a pretty popular laptop model (its screen is 1920x1200 at 13", around 170dpi; 'comfortable' DPI for a laptop display is 120-130).

Yes, but people mean different things when they say fractional scaling. We can enable the experimental settings (or get upstream to stop considering it experimental).

But some people consider the fractional scaling we get that way to not be 'proper' fractional scaling, because clients only get integer scale values - GTK apps still render at 2x if you set the scale to 125%.

Huh. What does that mean in practice, though? I mean, from my point of view this feels weird because all the objections make me feel like this should be more broken, but for me it really isn't. The extent of the weirdness I suffer seems to be "non-Wayland-native apps are a bit fuzzy".

"GTK apps still render at 2x if you set the scale to 125%" makes it sound to me like some apps should look unreasonably huge on my screen, because I use 125% scaling and I run GTK apps. But I don't recall ever seeing an app that behaved like that? I think a couple of years ago some apps would be very small, like they weren't being scaled at all, but I don't remember seeing anything very big.

gtk (and other UI?) Wayland apps do 2x rendering and then that is scaled down (by the compositor?) to fit 1.25 scaling.

xwayland apps do 1x, but then this is scaled up to 1.25x.

These are all fractional scaling based on integer scaling.

For me atleast, in practice the former looks sharp, the latter looks blurrier.

The above exists independent of the new wayland fractional scaling protocol that has recently been agreed.

There was talk about someone investigating whether different openGL scaling methods (AFAIK GL_NEAREST Vs GL_LINEAR) would result in even better results. I haven't seen anyone do that analysis yet and chances are it still needs doing.

I'm going to schedule this topic for next week's meeting.

Discussed with Jonas and Garnacho at today's meeting. Agreed:

• mutter developers to enable fractional scaling setting, no longer experimental
• Allan to investigate design for system settings
• Allan to investigate how to warn users about blurry XWayland applications

Discussed with Jonas and Garnacho at today's meeting. Agreed:

• mutter developers to enable fractional scaling setting, no longer experimental
• Allan to investigate design for system settings
• Allan to investigate how to warn users about blurry XWayland applications

Thanks Michael. I don't think there will be a "perfect" solution anytime soon when it comes to supporting legacy and new GTK apps. Including this is the lesser evil hopefully.

I did notice that the flatpak for the Element webapp gives sharp text, while the flatpaks for Slack and Discord webapps give fuzzy text. I think they're all very similar things, so it might be nice if we could get the Slack and Discord flatpaks to do whatever the Element one is doing that results in sharp text (not sure what that is yet). I'll have to see if any contact methods for those flatpaks result in a response...

I think Element is Wayland native, while Slack and Discord are not. You should be able to verify with in various ways, e.g. the "picker" in looking glass then going r(0).get_parent() on the picked actor, or the "xeyes" trick.

ah, yeah, that was my guess but hadn't confirmed yet.

edit: the Discord flatpak can be run in Wayland mode just by doing flatpak override --user --socket=wayland com.discordapp.Discord, that works fine, no more blurry text. There seems to be more complexity around Slack. I don't think just flatpak override --user --socket=wayland com.slack.Slack does the trick. I found some issues on the wrapper's github with some discussion, but couldn't for sure figure out how to get it in Wayland mode.

As a small update, we've done some investigations into improving handling of fractional scales in GTK. The Vulkan renderer has recently seen some improvements for doing aa rendering of lines, gradients and textures. That work would need to be transferred to the GL renderer for making it beneficial to the wider public.

Discussed with Jonas and Garnacho at today's meeting. Agreed:

• mutter developers to enable fractional scaling setting, no longer experimental
• Allan to investigate design for system settings
• Allan to investigate how to warn users about blurry XWayland applications

It would be nice to see a status update here from both mutter developers (@jadahl @garnacho @fmuellner) and design (@aday)

mutter developers to enable fractional scaling setting, no longer experimental

There has not yet been an upstream decision to flip the switch, and what we decided then IIUC was a downstream flip. I have prepared a downstream patch for this last week, but I was trying to find the comment you just quoted to add to the commit message. I'll move that forward now that I thanks to you found it!

Allan to investigate design for system settings

I have mockups, but didn't finish updating the newest revision in time for the UI freeze. I can finish them (aftre the RC this weekend), and we can downstream patch g-c-c if we want to.

Allan to investigate how to warn users about blurry XWayland applications

This was part of the mockups.

Just let me know if you need any more design input. We could go for an interim solution that implements only part of the mockups.

Created https://src.fedoraproject.org/rpms/mutter/pull-request/39 and https://src.fedoraproject.org/rpms/gnome-control-center/pull-request/18. The latter doesn't contain the implemented mockups for selecting scales, and only adds the legacy compat toggle.

We discussed this issue at today's working group meeting.

The working group would like the issue to be resolved for F39, as we had planned. For now, we've decided to merge the mutter PR in time for beta. We can potentially revert it before final, though we'd prefer not to.

The gnome-control-center change is trickier. We'd prefer not to have an untranslated setting, but we're also uncertain why this setting is necessary. @jadahl what's your view on that?

any change for Beta will require an accepted FE bug at this point, as we're in freeze.

The gnome-control-center change is trickier. We'd prefer not to have an untranslated setting, but we're also uncertain why this setting is necessary. @jadahl what's your view on that?

I think the gnome-control-center change is critical, and should land both or none for the Beta, as we need a non-terminal/dconf-editor way to revert back to the existing solution, so that e.g. people using IntelliJ on HiDPI monitors can get their sharp text back.

Discussed with Jonas and Garnacho at today's meeting. Agreed:

• mutter developers to enable fractional scaling setting, no longer experimental
• Allan to investigate design for system settings
• Allan to investigate how to warn users about blurry XWayland applications

https://github.com/ValveSoftware/steam-for-linux/issues/10050

And the most annoying problem which couldn't workaround-ed - all games works now in full hd instead of 4K resolution.

There are some potential for implementing work-arounds in Xwayland for such fullscreen game issues, by extending the RANDR emulation to include resolutions larger than what the compositor advertises, and then selecting that resolution in the game.

@jadahl Should I fill a issue for it here https://gitlab.freedesktop.org/xorg/xserver/-/issues? Or is there already exists task for this?

The gnome-control-center change is trickier. We'd prefer not to have an untranslated setting, but we're also uncertain why this setting is necessary. @jadahl what's your view on that?

I think the gnome-control-center change is critical, and should land both or none for the Beta, as we need a non-terminal/dconf-editor way to revert back to the existing solution, so that e.g. people using IntelliJ on HiDPI monitors can get their sharp text back.

With fractional scaling on, if someone selects an integer scale value, they will still get a fuzzy Intellij?

With fractional scaling on, if someone selects an integer scale value, they will still get a fuzzy Intellij?

Yes.

It's just too late to add the setting to gnome-control-center for F39. It needs to be translated upstream, and it's too late for that.

My $0.02: let's defer this to F40, but land it now, not later, so we have it enabled in rawhide ASAP and it doesn't slip again. We have already determined that having fractional scaling enabled by default is more important than other considerations. It's unfortunate if IntelliJ or 4k gaming does not work well, but fractional scaling is more important.

It's just too late to add the setting to gnome-control-center for F39. It needs to be translated upstream, and it's too late for that.

I'm inclined to agree.

Well, uh, while this ticket was chinwagging, since https://bugzilla.redhat.com/show_bug.cgi?id=2237469 was accepted FE, we already pushed https://bodhi.fedoraproject.org/updates/FEDORA-2023-d40f5b287a stable. Is this going to be a problem?

No, just drop the patch after beta freeze has ended.

Or alternatively: accept that fractional scaling's time has come a little sooner than the UI for the off switch. For years users who required fractional scaling had to use the command line to turn it on. It's not the end of the world if the reverse is true for one release.

OK. So we're fine leaving it in for Beta? We can revert, if needed.

Yes, we're fine with it.

Or alternatively: accept that fractional scaling's time has come a little sooner than the UI for the off switch. For years users who required fractional scaling had to use the command line to turn it on. It's not the end of the world if the reverse is true for one release.

I'd rather just do this, people have complained a lot more about the lack of the option enabled by default for years.

This thread on GNOME Discourse needs some help from the mutter developers.

We offer the ability for apps to indicate they're HiDPI aware and let them handle scaling. Otherwise we scale them the same way.

Maybe this is what mutter should be doing? Because users don't seem to be complaining about KDE's behavior?

https://bugzilla.redhat.com/show_bug.cgi?id=2238905 is a report where it seems like fractional scaling seems to now be auto-detected, like we auto-set integer scaling for hidpi displays before. Was that intended? I wasn't necessarily expecting it. Thanks!

I believe we do this with non-fractional modes too, so enabling fractional modes should just allow them to be set if it believes them to be more correct.

Well, in theory sure, but in practice it seems like a much trickier thing to get right. At integer scaling, the 'buckets' are pretty huge - I think we only apply 2x scaling if your DPI is over like 180 or 190 or something, at which level 1x scaling is virtually unreadable.

It seems like it'll be much harder to come up with lines between 1x, 1.25x, 1.5x, 1.75x and 2x. Those are much narrower distinctions, and probably different people would make different choices on the same monitor sometimes...

edit: heck, at this level you have to start reckoning with the difference between laptop and desktop displays. In general people sit closer to laptop displays, so there's about a 20dpi difference in 'effective' comfort - 130dpi on a desktop display is pretty awkward (for me) but 130dpi on a laptop display is fine. I might well want 125% scaling on a desktop 130dpi display, but not a laptop one...

We discussed this issue at yesterday's working group call. The group is reluctant to drop this feature for F39, given that it's something that we've wanted for so long.

We have decided to keep the current situation as it is for now, but we'd like to discuss it again next week ideally with participation from @jadahl .

sure, I guess the upside is, if we get it "wrong" by 25% it's not the end of the world. maybe all we need is to make sure people know this exists, and what setting to change if they want something different.

we also got a report from someone which seems to be about the issue that the fractional scaling approach is used even for integer multiples now(?), and they can't manage to disable it:

https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/XPJMMYAZKXYBT562BBQ5SO7O2BKKSILO/

do we have any advice for that situation? thanks!

Hello! Silverblue 39 beta tester here. Managed to restore the old behavior by removing scale-monitor-framebuffer from org.gnome.mutter.experimental-features. Hope this helps people experiencing blurry xwayland apps using 2x scaling until the user interface is ready.

Command:

gsettings set org.gnome.mutter experimental-features "[]"

I just hit the same issue after upgrading to Fedora 39. I got very blurry XWayland windows (which is super super bad for text-heavy things, like VSCode). I also get weird scaling behavior by default (like 250% on my laptop - which is not what I want - which previously defaulted to 200%).

Looks like mutter package now ships with scale-monitor-framebuffer experimental feature enabled by default, so if users haven't changed this setting and upgrade to Fedora 39, they will get this. I don't think that's a good idea (especially since it regresses the integer scaling case), which is why I also opened a bug atout it ...

https://bugzilla.redhat.com/show_bug.cgi?id=2240034

I've documented this change in this Common Issue:
https://discussion.fedoraproject.org/t/fractional-scaling-in-gnome-45-makes-some-applications-blurry/90393

I'd appreciate if people read it and improved the article (anyone should be able to edit it, I think) or suggested changes.

I have two questions:
1. Will the graphical toggle between integer and fractional scaling be available in gnome-control-center in F39 Final? That would be easier for people than running gsettings commands. (It would also be nice if switching the toggle would suggest a re-login).
2. Can we get rid of the blurriness at 200%/300% factor even if fractional scaling is enabled? This must be very confusing for regular people. If we could use the integer scaling approach for integer factors even if fractional scaling is enabled, we would be able to get rid of the toggle (see 1.), the documentation would be much simpler, and the people in general would have crisper image (because many people who'll set 200% will not realize that there's a way to make it less blurry).

1. The Working Group agreed it's too late to add UI for F39. Any UI would be a F40 feature at this point. We're not convinced that the proposed on/off switch UI is desirable anyway; all we really want is an option to set the scale factor, which already exists in the Displays panel. Any proposed UI should undergo review by GNOME design team and land upstream first.

2. The Working Group was confused by this as well. We were specifically confused why there is any behavior change when the scale factor is 100%, but yes, I suppose that same question applies to the other integer scale factors too.

We do have a consensus that while we're disappointed that XWayland applications are blurry, we're not willing to delay fractional scaling any further. Although we want all Linux applications to work well in Fedora Workstation, in this case we've been forced to choose between compatibility with modern hardware vs. compatibility with legacy applications. We choose to prioritize modern hardware. It would be really nice if we didn't have to pick one or the other.

We do have a consensus that while we're disappointed that XWayland applications are blurry, we're not willing to delay fractional scaling any further.

My personal view: if the blurriness issues are severe, then we should delay fractional scaling until we have a setting to allow users to opt out. (By severe, I mean if it results in commonly used or important apps being difficult to use.)

It's disappointing, but people not being able to use the most common IDEs without having to dig into gsettings is worse than losing out on fractional scaling for 39.

Yeah, FWIW, I was in favor of this feature but did not realize it causes regressions at integer scaling values, or that autodetection would be applied to fractional scaling values. Somehow I kinda envisioned this as "everything will be the same as before except people who need it can manually select fractional scaling values".

That's my bad for not researching sufficiently, but it does mean I'm less in favor of the change than I was before. I especially think the 'fuzziness at integer scaling values' problem is bad and we should reconsider the change if we can't fix that. Sorry again for not realizing sooner.

We were specifically confused why there is any behavior change when the scale factor is 100%,

@catanzaro Sorry, I must've missed it. What is the problem at 100%?

I wouldn't want to work 8h in a blurry IDE, even if it's "just a bit" blurry, and I'd be pretty disappointed if I had to type obscure commands in a terminal to make that happen.

Without the Settings change, that is the current state, which is why it is still my opinion that either both the mutter and gnome-control-center change land, or none, for F39.

Can someone point to a succinct summary of the technical background here. What does the setting under discussion actually control?

We were specifically confused why there is any behavior change when the scale factor is 100%,

@catanzaro Sorry, I must've missed it. What is the problem at 100%?

The complaint here is that XWayland apps become fuzzy/blurry. Is that not true?

I wouldn't want to work 8h in a blurry IDE, even if it's "just a bit" blurry, and I'd be pretty disappointed if I had to type obscure commands in a terminal to make that happen.

I wouldn't want to use that app either. It's extremely unfortunate that we seem to be forced to choose between fractional scaling vs. blurry applications.

The complaint here is that XWayland apps become fuzzy/blurry. Is that not true?

Only above 100%. At 100%, everything is sharp, at least for me (tested PyCharm, Chromium, Steam).

We've agreed:

• Michael to revert patch in Fedora 39 but not rawhide, so change is deferred but not reverted
• Allan to close gnome-control-center toggle switch proposal, this is rejected

Allan to close gnome-control-center toggle switch proposal, this is rejected

The control center issue [1] is about more than the switch toggle, and I'm not sure it needs closing right now. I'll certainly be following up to try and figure out a better design, though.

[1] https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2516

• Michael to revert patch in Fedora 39 but not rawhide, so change is deferred but not reverted

Unfortunately, the revert caused a regression for people who enabled non-integer display scaling during the period when it was enabled:
https://gitlab.gnome.org/GNOME/mutter/-/issues/3057

Are you going to handle this? Or should I just document it? (I'd of course prefer the former ;) ).

Unfortunate. I don't know how to handle that, sorry. :( It will need to be looked at by mutter developers.

@catanzaro The patch is ready and I've requested a freeze exception here:
https://bugzilla.redhat.com/show_bug.cgi?id=2242061
Can somebody here please handle building it and submitting an update? Thanks!

Thanks! I went ahead and backported the patch to mutter-45.0-4.fc39 and mutter-45.0-6.fc40, builds are under way.

https://bodhi.fedoraproject.org/updates/FEDORA-2023-725a18d9f1

Hello,

I’m a new HiDPI screen user and I was wondering if the current state of Fedora 39 beta lets me enable fractional scaling and how? If it’s possible, will the situation remain the same for Fedora 39 stable?

It's not supported yet, sorry, although there is an experimental mutter setting somewhere that you can use.

• Michael to revert patch in Fedora 39 but not rawhide, so change is deferred but not reverted

So the current status quo is XWayland applications are blurry in rawhide and will be blurry in Fedora 40. Are we willing to ship Fedora 40 in this state? If not, we'll probably need to give up on fractional scaling altogether, because it seems unlikely that our developers will present us with different options in the future than we've had thus far. At least, I'm not aware of any more work on this.

Unless we have any update from the mutter side? @jadahl?

IMO to get fractional scaling in F40 the only reasonable thing to do right now is to expose the toggle between legacy and new in Settings. It has already made users in Ubuntu happy for a few releases already. The alternative is that Fedora does nothing, and just waits for upstream to do it instead, but in my opinion, we can take a lead here, we just need that trivial escape hatch. Doing this was also the plan for F39, only that things settled far too late in the cycle to make it possible.

The design is again possibly changing, I believe,, so I guess it also depends on how that'll turn out. Unfortunately I won't be available to implement those design changes however.

I know it's awkward to have to have such a setting, but the world isn't perfect, and insisting it must be isn't really that helpful.

As far as I'm aware, this issue is waiting on @otaylor to provide a write up of the call that we had about it on 11 October. At least, that's what I'm waiting on before I take another look at the designs.

I know it's awkward to have to have such a setting, but the world isn't perfect, and insisting it must be isn't really that helpful.

I think we have a strong consensus that we are not willing to add the old vs. new toggle switch (escape hatch) that you're requesting.

As far as I'm aware, this issue is waiting on @otaylor to provide a write up of the call that we had about it on 11 October. At least, that's what I'm waiting on before I take another look at the designs.

Hm, @otaylor do you remember what we discussed last month and are you still planning to work on this?

I can't remember what we discussed last week. I fear that after one month, whatever we discussed has likely been forgotten.

I had a meeting with @jadahl, @mclasen, and @aday and have the work item to do a nice friendly write-up of what's involved. That's been backed up behind other work, but still on my agenda. Hopefully I haven't forgotten everything!

OK.

I'll set milestone to Fedora 40, since the status quo if we do nothing will be blurry XWayland applications.

Relevant: This week in KDE: non-blurry XWayland apps!

Owen has written documentation explaining the problems here.