fesco

#3075 Proposal for F39 Final FESCo Blocker: RHBZ#2240034
Closed: Invalid by decathorpe. Opened by decathorpe.

Closed: Invalid
Reopen Issue

I propose https://bugzilla.redhat.com/show_bug.cgi?id=2240034 as a FESCo blocker bug for F39 Final. It is unclear to me whether the Release Criteria for Final releases cover this case (though they do have a clause about "games must be displayed correctly"): https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Window_manager_functionality

TL;DR:

GNOME 45 changed its default settings to enable an experimental feature for fractional scaling. However, the way this feature is implemented causes two major regressions for users with HiDPI screens, especially when using integer scaling factors (i.e. 200%, 300%):

  • Applications that rely on XWayland and which previously did X11-native rendering with integer scaling (i.e. 2x) now render at 1x and are upscaled in software, resulting in "blurry" window contents. This is especially bad for text-heavy applications, like VS Code or JetBrains IDEs, which either do not enable Wayland backend for rendering by default (Electron), or do not support Wayland yet at all (Java).
  • Games and other fullscreen applications only see the "scaled" resolution of the screen and not its native resolution. This makes it impossible to play games at "native" screen resolution. For example, with a 4K (2160p) screen, using 200% scaling, games can only render to a buffer the size of a FullHD (1080p) screen.

Additionally, there is no way to revert to the "old" implementation that only supported integer scaling available in the GNOME Settings UI, since it was not done in time for GNOME 45. Reverting to the old behaviour is only possible via CLI command or using dconf-editor (not installed by default).

For this reason, I do not think it is acceptable to regress two common use cases (popular IDEs and other Electron apps, almost all games) with the default settings.

+1

To be clear, are we voting on "F39 must revert to integer scaling" or are we voting on "F39 cannot ship software-upscaled XWayland windows"? This is the difference between FESCo saying "the current state is unacceptable" and FESCo saying "you must go back to the previous state".

I'm inclined to block on "the current state is unacceptable", but I would like to leave the implementation to the Workstation WG to figure out.

I'm okay with blocking on "current state is unacceptable" rather than forcing a total revert.

The fractional scaling issue has been a complaint from users and reviewers for years now, and I would rather see if something can be done about XWayland stuff instead.

Yesh, sorry for the ambiguity in the initial proposal.

I wanted to express "current state is unacceptable", not "fractional scaling bad".

In fact, I want to use fractional scaling (I've monkey-patched it for my workstation by using 200% scaling with 75% font scaling for years now, and I'd very much like to just use 150% scaling instead). I've tried the setting that has now been switched on by default with every new GNOME release for a year or two (not sure how long it's been there), but the situation for XWayland windows has not changed since then.

I would be OK with both reverting to the previous scaling behaviour or with fixing scaled rendering of XWayland windows instead. But the current implementation has the worst of both worlds.

Could FESCo maybe consider at least talking to the WG about this before simply taking a vote to override its considered opinion on this decision? I'm worried about what signal it sends to WGs if FESCo just starts overriding their design decisions about their desktops by fiat.

I'm deliberately not voting until we talk to the WG first.

Sorry, I thought this comment was supposed to convey the opinion of the WG:

It's a very frustrating choice, but we [Workstation Working Group?] chose to prioritize modern hardware rather than legacy applications, and I'm confident that's the correct choice for Fedora Workstation.

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

If that was not the case, let's wait with voting on making this a blocker bug until the WG can this discuss this (again?).

Sorry, I thought this comment was supposed to convey the opinion of the WG:

I think that's a fair summary of our most recent discussion of this issue, which was last week. That said, we have it on the agenda again for tomorrow's meeting:

Workstation WG has agreed to revert this patch in Fedora 39. A blocker designation wouldn't hurt.

We are leaving the change in rawhide for now to ensure we don't lose momentum. So, we'll still have this problem again next release unless it can be resolved somehow.

Actually, I'll leave that bug report open to track that the problem still exists in rawhide, so let's not mark it as a F39 blocker please.

If we want to be really sure this gets in before Final, we can file a separate blocker bureaucracy bug and have fesco nominate that as a blocker?

Yes, but it's unlikely to be necessary because freeze does not begin until Tuesday and presumably the update https://bodhi.fedoraproject.org/updates/FEDORA-2023-e667b725bb should land before then.

OK, it's queued for stable now. I guess we can close this, then?

Yes, thank you to everyone involved in resolving this so quickly.

Metadata Update from @decathorpe:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.