after update steam client to version 1676680477 scaling being broken on pages (game library and chat)

[NTMan]

Your system information

• Steam client version (build number or date): 1676680477
• Distribution (e.g. Ubuntu): Fedora Rawhide
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

after update steam client to version 1676680477 scaling being broken on pages (game library and chat)

last good version for me is 1675997500

Steps for reproducing this issue:

[CoelacanthusHex]

An Off-topic question: How do you downgrade steam to the previous beta version?

[cprn]

Same issue on up-to-date Manjaro with updated Steam client and beta opt-in (NVIDIA proprietary driver). Can't read game titles in 4K without scaling and with Deck UI running at about 3fps it's very cumbersome to start a game.

Workarounds:

1. opting out of beta fixes the main window scaling (Deck UI is still a slideshow)
2. alt+enter starts a good-old Big Picture mode that works flawlessly (for now)

[hoxu]

I just upgraded to 1676836260, and HiDPI scaling is indeed now broken.

Opting out of the beta participation fixes the problem, as expected.

Please add an automated regression test for HiDPI.

[TheGhostHybrid]

Chiming in to say I have the same issue. The window is fine, but the content within the viewport no longer scales properly. In addition, I have this issue that happens whenever I view a non-Library page:

It seems to resolve itself when I close the window and re-open from the system tray. However, when freshly started, the issue comes back.

[Anarch157a]

Chiming in to say I have the same issue. The window is fine, but the content within the viewport no longer scales properly. In addition, I have this issue that happens whenever I view a non-Library page: (...) It seems to resolve itself when I close the window and re-open from the system tray. However, when freshly started, the issue comes back.

I have this issue too, I don't need to close the window and re-open from the tray icon, changing the page to Library, then back to the previous one makes it render properly. This is much quicker than re-opening

[NTMan]

In the version 1678845529 fixed scaling in library, but scaling still not working in "game properties" and "steam library folders"

Also scaling didn't work in windows "big picture configuration", "desktop configuration" and "guide button chord configuration"

[frikisama]

Is it just me, or does the newly enabled scaling look like actual high DPI rendering instead of simple 2x scaling? It looks very crisp now, where it was a bit blurry before, IIRC.

Thanks to whoever was involved! :)

[Lastique]

@kisak-valve Is there a workaround? The game properties window is barely readable.

[Seegras]

For me, the scaling issue is fixed on the Library with 1679024366, but still present in the properties window.

[friedc]

scaling still not working in "game properties" and "steam library folders"

Also scaling didn't work in windows "big picture configuration", "desktop configuration" and "guide button chord configuration"

I can confirm that for me the mentioned windows are also too small (not scaled to 2x size). I do not participate in the Beta.

About Steam

Steam client application:
Built: Mar 24 2023, at 17:20:43
Steam API: v020
Steam package versions: 1679680416

[NTMan]

And again scaling is broken since 1679950905 version.
Is it really is no one developer at Valve having 4K monitor with scaling?

[yhojann-cl]

This problem has not been assigned to anyone for more than two months. Is there any news?, this problem also happens in the latest stable version 1679680416

[Grauiton]

FYI for Valve:

GTK4 dropped usage of GDK_DPI_SCALE.

KDE Plasma followed this by dropping the use of GDK_SCALE / GDK_DPI_SCALE starting with Plasma version 5.27. KDE Plasma instead recommends using xsettingsd to communicate scaling settings to GTK applications in X11 sessions.

[arazilsongweaver]

Wayland DPI scaling is completely broken as of the "big" Steam beta update released on 2023-04-27. Everything appears very tiny on a 4K screen and it is extremely difficult to use.

Example screenshot from the 2023-04-27 update:

[NTMan]

With update 1682634349 in addition to library broken scaling on store pages.

[TheGhostHybrid]

The Steam window over top of a properly-scaled window (Quod Libet) to show the stark scaling difference.

[anyoneyun]

Same issue here on Manjaro KDE, it has been a problem for months now, as a comment stated earlier, kde changed the way scaling works and now it doesn't use GDK scale anymore. This has been true since kde 5.27

[Grauiton]

The solution for Valve is really simple:

If the GDK_SCALE environment variable is zero-length or not set, then instead use the value for Gdk/WindowScalingFactor in ~/.config/xsettingsd/xsettingsd.conf.

That's it.

[yhojann-cl]

Why not use the same window to render all the others instead of doing it separately? In this way the scaling would depend on a single window instead of fighting with the rest. For example, I use two monitors and when a window opens like the update window, news, launcher, etc., they open on a different monitor than the one where steam is running. They could solve all those problems including the scaling thing if they integrated all the other windows inside of steam and not outside of it.

[Arcitec]

What is this? A GUI for ANTS?!

🐜

Tried the latest beta today. Totally unusable. Switched back immediately.

[TDuffinNTU]

XWayland will be supported for years if not decades to come. There is no incentive for Valve to spend engineering resources fixing a bug that affects < 1% of their users.

This issue affects ALL high DPI displays, regardless of the desktop's choice of display backend. I get the same problem (and same solution, at least!) on X11 proper.

(Aside from the point, most users in 2024 are Wayland. If you consider that every Steamdeck runs Wayland (in game mode) and almost all modern distros ship Wayland as the default backend, I can't imagine most people notice enough of a change to know they've migrated).

---

As for others with high DPI displays -- Just don't use the .deb and use the flatpak where you can enforce scaling as a launch argument via flatseal. If you're stuck with the .deb, you can add the argument there too but you'll have to modify the .desktop file IIRC. One of the benefits of flatpak is being able to manage this like CLI args in one utility.

[tesfabpel]

BTW, a point that it seems no one has still touched is mixed-DPI setups. This makes the slider just a workaround because it won't work in those situations because it depends on what monitor the Steam's windows are (and there could be multiple Steam windows open at the same time and on different monitors).
Anyway, until Valve fixes the issue in the correct way, the slider may be a good option (in the future, it could work as a global scale multiplier by the Steam client, like if you want bigger UI elements to see them better).

[OdinVex]

@tesfabpel Very true but an exposed float/slider would do wonders for so very many. Certainly more than <1% than JFR was trying to claim. You don't need a hiDPI display to want to change DPI. I know some visually impaired people that need this.

@TDuffinNTU Not everyone uses Flatkrap. I'm using a native install and it's still a crud solution. I ended up just setting an environmental variable for the whole system to affect all users. It's bull to have to do that per system or even per user.

[jfroy]

Steamdeck, which is not affected by this issue at least in gamescope, represents 40% of Linux users (https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam?platform=linux). Combined with Linux's global 1.97% share (https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam?platform=combined), that means desktop Linux has a 1.182% share. So OK, slightly above 1%.

Of course, this ignores the share of Linux desktop users who have displays with a resolution above 1080p (19.08%). If you factor that in, you're down to 0.23% of users who may be affected by HiDPI issues on desktop Linux. I grant that primary screen resolution is not a direct signal for display DPI, but it is a good estimate.

And of course, the accessibility value of DPI scaling is great, so those users would I'm sure appreciate better control. Although I will say those users would generally be much better served by macOS which has far better accessibility controls than either Windows or any desktop Linux environment.

[OdinVex]

Of course, this ignores the share of Linux desktop users who have displays with a resolution above 1080p (19.08%). If you factor that in, you're down to 0.23% of users who may be affected by HiDPI issues on desktop Linux. I grant that primary screen resolution is not a direct signal for display DPI, but it is a good estimate.

Again, not everything is about hiDPI. In my case, yes. Others such as visually-impaired, no. Others that just want to change size, no. Assumptions regarding data..*sigh*.

Not to mention you think those surveys represent all Steam users. Those represent the ones that allow the survey to run and report data afterwards (if submitted). Assumptions regarding data..*sigh*.

[jfroy]

Of course, this ignores the share of Linux desktop users who have displays with a resolution above 1080p (19.08%). If you factor that in, you're down to 0.23% of users who may be affected by HiDPI issues on desktop Linux. I grant that primary screen resolution is not a direct signal for display DPI, but it is a good estimate.

Again, not everything is about hiDPI. In my case, yes. Others such as visually-impaired, no. Others that just want to change size, no. Assumptions regarding data..sigh.

Not to mention you think those surveys represent all Steam users. Those represent the ones that allow the survey to run and report data afterwards (if submitted). Assumptions regarding data..sigh.

I did mention accessibility, and I tried to state my assumptions. No data set is perfect, but making decisions informed by imperfect data, knowing the assumptions you're making, is better than making decisions based on gut feeling or ideology. I don't know if Valve has ever stated whether or not the Steam hardware survey is statistically significant (e.g. how many users get prompted, how many users agree to send the data). But if it is statistically significant, then we can make conclusions about the overall Steam user population from it. They (Valve) certainly suggest that it is and that game developers and publishers can use it to make addressable market decisions.

[OdinVex]

But if it is statistically significant, then we can make conclusions about the overall Steam user population from it.

This won't have anything to do with attempting to enumerate visually-impaired or 'prefer different size'. You can't make any conclusion except when people fuss for the feature. Edit: In short, bad statistician!

[TDuffinNTU]

The simple solution to people who dont think this feature is worth developing: dont bother commenting on this issue which doesn't affect you!

I can't imagine some here would have the audacity to comment on an issue for, say a Windows application and complain because it doesnt affect them as a Linux user!

If this issue truly isn't on Valve's roadmap then at this will serve as a reminder to them of the users who will benefit! I wonder if the flatpak repackage can show an alert like it does regarding udev rules.

[DDR0]

Issue is still affecting me here on KDE Neon 5.72; Steam is very, very tiny on my high-dpi screen.

[kakra]

There only two ways of enabling the Steam's fractional scaling along with the rest of the system:
Using steam -forcedesktopscaling 1.5 %U ARGUMENT

Works for me, wow, thanks @MartinVonReichenberg - using KDE Plasma with fractional scaling of 1.5. Finally, I don't need to move my nose 5cm in front of the screen to read the Steam client.

For some unknown reason, very rarely (I mean "extreme rarely"), the Steam Client actually used 1.5 scaling even without this setting - but in only lasted until the client restartet, and it always only affected Steam when autostarting with the session if it worked.

Interestingly, with -forcedesktopscaling 1.5 the client renders much faster (at least it feels much snappier, scrolling is still sluggish on those fancy overlay community news).

I used the KDE menu editor to change the parameters, and also adjusted the autostart entry the same way.

[arazilsongweaver]

Steam shipped a major client update on 27 February 2024 that updated the Chromium runtime and was described as "clearing [the] path for further updates soon." Any chance that this glitch will get resolved in the near future?

[jarrard]

Slightly off topic.
I noticed for a long time now that steam UI has been flickering under Wayland, mostly in the top section.

Comes under the umbrella of UI issues Steam has.

[Seegras]

scaling now works for me. Except in steam overlay mode. There I have tiny windows...

[pohmelie]

@Seegras
Nah, scaling is not fixed

[ivanich]

Under Wayland in the kde plasma 6.0.1 scaling doesn't work for steam.

[jarrard]

pretty sure I got it working with nvidia 4090 of all things.

[ShalokShalom]

The recent update has fixed it for me.

[ShalokShalom]

Under Wayland in the kde plasma 6.0.1 scaling doesn't work for steam.

I am on Wayland with Plasma 6.0.1 and it works for me. 2.8K screen on a laptop:

[ivanich]

Under Wayland in the kde plasma 6.0.1 scaling doesn't work for steam.

I am on Wayland with Plasma 6.0.1 and it works for me. 2.8K screen on a laptop:

No luck here

Ofc it can be workarounded with STEAM_FORCE_DESKTOPUI_SCALING=2

[ShalokShalom]

I had already forgotten, that I had that setting in and it does not work without it as well.

I had been at the point for the past weeks that even that setting wouldn't change anything.

So we are back to square one and still no signal from Valve employees.

[kakra]

So we are back to square one and still no signal from Valve employees.

It is probably very hard to maintain due to the various components which do things differently (e.g., the UI toolkit does not support fractional scaling), and we have a mix of different technologies (some of the UI renders with gtk/gdk, some renders with Chromium/webkit), and we have a mix of different rendering targets (sometimes the UI renders to desktop surfaces, sometimes it renders to overlay surfaces), plus Steam seems to do some window management by itself because it doesn't use server-side decorations. In my case, it messes up its position and size while scaling is forced if monitors turn off or on, or if I just minimize/restore the client. On the top, we now have Xorg and Wayland to care about, they should probably focus on Wayland because Xorg is going away within the next few years (I'm still using Xorg and will do so for a while, so it's probably not going to work well for me if they focus on Wayland).

So we are back to square one and still no signal from Valve employees.

I would at least appreciate some more testing of the known corner cases with and without forced scaling before they release a new client. Currently, it's a mess.

[ShalokShalom]

They could at least answer, for starters.

[D-Code]

Curious - entering Big Picture Mode and then exiting Big Picture Mode gives a correctly scaled interface.

[Lucretia]

Still a problem, still can't read the tiny arsed text that is literally 2 mm tall on this 4K screen. I've tried with and without beta, going into big picture mode and exiting like someone else said with and without interface scaling selected, I've tried changing DPIScaling inside ~/.steam/ to 2.0, Gdk/WindowScalingFactor inside ~/.config/xsettingsd/xsettingsd.conf to 2.0, steam -forcedesktopscaling 2.0 # and 1.25 and NOTHING works.

[Lucretia]

I just found STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam which WORKS!

[MartinVonReichenberg]

I just found STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam which WORKS!

You looked far:
It is mentioned here, but lost in thread . . .

[Lucretia]

I just found STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam which WORKS!

You looked far: It is mentioned here, but lost in thread . . .

That variable is not mentioned in that post.

[MartinVonReichenberg]

I just found STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam which WORKS!

You looked far: It is mentioned here, but lost in thread . . .

That variable is not mentioned in that post.

No it is not - my bad.

The issue, however, can vary from distro to distro as Arch+ uses Steam Native and Stream Runtime in which -forcedesktopscale might work only for one of those. Also, there have been changes to libraries after several months which potentially affected this issue and its 'temporary solution(s)'. So it is easy to 'get lost'. 😵

[Lucretia]

I just found STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam which WORKS!

You looked far: It is mentioned here, but lost in thread . . .

That variable is not mentioned in that post.

No it is not - my bad.

The issue, however, can vary from distro to distro as Arch+ uses Steam Native and Stream Runtime in which -forcedesktopscale might work only for one of those. Also, there have been changes to libraries after several months which potentially affected this issue and its 'temporary solution(s)'. So it is easy to 'get lost'. 😵

As I said, that option does not work here (Gentoo).

[Woovie]

Using Arch, flatpak Steam. In order to use the env var, I had to copy the generated .desktop and modify the Exec.

In ~/.local/share/applications/ there is this symlink:

com.valvesoftware.Steam.desktop -> /var/lib/flatpak/app/com.valvesoftware.Steam/current/active/export/share/applications/com.valvesoftware.Steam.desktop

I copied the file into the same directory, named it something else, and made these changes:

❯ diff com.valvesoftware.Steam.desktop steam-fixed.desktop
30c30
< Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/steam --file-forwarding com.valvesoftware.Steam @@u %U @@
---
> Exec=/usr/bin/flatpak run --env=STEAM_FORCE_DESKTOPUI_SCALING=1.5 --branch=stable --arch=x86_64 --command="/app/bin/steam" --file-forwarding com.valvesoftware.Steam @@u %U @@

Note the usage of --env, you cannot simply quote the command and add it to that flag.