Steam client does not use Gnome's scaling setting
Hello @NTMan, HiDPI is currently disabled by default at Steam -> Settings -> Interface -> Enlarge text and icons based on monitor size (requires restart). Please confirm this setting is checked.
Yes, this option enable scale to 200% but client still ignore desktop settings. If desktop switch to 100% scaling steam client after restart will work with 200% scaling. It's not good.
Second issue this seting not affected to splash screen. (Window which show update steam message)
Thanks for checking, marking as a feature request for Steam to consider GTK+'s scaling factor with its HiDPI support.
As for the initial update window, that is intentionally very basic so that it has as few requirements as possible while doing updates.
How is basic functionality for 4K monitors on Linux a feature request? It's basically unusable on my 13 XPS, you can't even see to login it's so small
Ditto.
Same problem for me on Steam. The scaling settings from GNOME are not respected. Is there any movement towards a fix on this?
If you can manage to actually see to login, there is a setting you can toggle to make it usable ish
Well, I can log in and it is usable for me, just not a very pleasant experience. Regarding the setting, do you mean the interface setting, that says 'Enlarge text and icons based on monitor size'? If so, I do have it enabled/checked. Does not do anything for me, no different to when I have unchecked.
Ya that made one made it slightly larger and useable but still small
That "enlarge text" checkbox does nothing for me on Ubuntu 18.04 / Dell Precision M3800.
You might want to start Steam with the environment variable GDK_SCALE=2 to ensure HiDPI support.
AFAIK GNOME and GTK internally uses XSettings to share information about scaling, but Steam only recognizes the environment variable (which is also recognized by GTK, and used in desktop environments without XSettings, such as KDE), not XSettings.
You might want to start Steam with the environment variable
GDK_SCALE=2to ensure HiDPI support.AFAIK GNOME and GTK internally uses XSettings to share information about scaling, but Steam only recognizes the environment variable (which is also recognized by GTK, and used in desktop environments without XSettings, such as KDE), not XSettings.
No effect in cinnamon, won't use gnome because it doesn't support zooming in on the screen with the mousewheel, not even an option to manually add it, tried looking for software too but nope, gnome is not user friendly, only developer friendly, that's the wrong way round for software
Issue still present. Ubuntu 18.04.
Still having this issue 19.10 and when using 125% scaling of wayland. Pleeeeese look into it Steam
You might want to start Steam with the environment variable
GDK_SCALE=2to ensure HiDPI support.
Thanks for this workaround! I created a desktop starter for steam accordingly (see attachment). After saving it in your local ~/.local/share/applications directory as "Steam HiDPI.desktop", a "Steam HiDPI" icon will appear in your gnome shell overview.
Issue still present in 19.10. If this was FOSS we would have fixed it ourselves by now. Simple GTK+ API call.
Big picture mode seems to scale correctly in 19.10. How is this not considered a bug?
The biggest cause of this problem I would reckon is because no base font size is used from what I've seen in the css files I found, I've only seen fixed pixel sizes, I suggest before you go back to this problem you make one global variable such as "BASE_FONT_SIZE" in everything that uses fonts whether it be css, js, C or something else, have steam set those variables at startup then make everything including UI elements calculate their size based on that, here's some example HTML/CSS I put together while looking for the optimal size for my projector that I wanted out of steam:
<!doctype html>
<html style="font-size: 8mm; padding: 0.2rem">
<head>
<title>Font-size test</title>
<style>
html, html *
{
font-color: gray;
line-height: 1.2em;
vertical-align: text-bottom
}
body {
border: 0.2rem solid blue;
margin: 0;
min-width: 50rem
}
.hbar
{
display: block
}
.hbar li
{
border: 0.2rem solid green;
display: inline;
display: inline-block;
padding: 0.2rem;
position: relative
}
.hbar li li
{
display: block
}
.hbar ul, .hbar ol, .hbar dl
{
display: none;
position: absolute;
top: 1.4em;
left: 0
}
.hbar a:hover + ul, .hbar ul:hover,
.hbar a:hover + ol, .hbar ol:hover,
.hbar a:hover + dl, .hbar dl:hover
{
display: block
}
img, .bg-img
{
background: gray;
border: 0.2rem solid gray;
display: inline;
display: inline-block;
margin: 0;
width: 5rem;
height: 7rem
}
.bg-img
{
background: no-repeat url("w3schools.jpg");
background-size: 100% 100%;
background-size: cover;
}
</style>
</head>
<body>
<div class="bar">
<ul class="hbar">
<li class="menu"><a>Store</a></li>
<li class="menu">
<a>Library</a>
<ul>
<li><a href="#lib_games">Games</a></li>
<li><a href="#lib_tools">Tools</a></li>
<li><a href="#lib_both">Both</a></li>
</ul>
</li>
<li class="menu"><a>Community</a></li>
<li class="menu">
<a>Font examples</a>
<ol>
<li><b style="font-size: 1.0rem">1.0rem</b></li>
<li><b style="font-size: 1.2rem">1.2rem</b></li>
<li><b style="font-size: 1.4rem">1.4rem</b></li>
<li><b style="font-size: 1.6rem">1.6rem</b></li>
<li><b style="font-size: 1.8rem">1.8rem</b></li>
<li><b style="font-size: 2.0rem">2.0rem</b></li>
</ol>
</li>
</ul>
</div>
<input style="width: 5rem" value="123456" />
<img id="bg-img"
src="https://www.w3schools.com/html/w3schools.jpg"
alt="W3Schools" />
<hr class="bg-img" />
<div class="bg-img"> </div>
</body>
</html>
Just swap out the image for whatever example image/s you need to work from, slap together a test app that modifies the base font-size then test on manjaro distro's via virtual box or something, if your code works there then it should work anywhere and put this issue to rest.
Same problem here:
- Fedora release 32 (Thirty Two)
- Mesa Intel® UHD Graphics 620 (KBL GT2)
- GNOME 3.36.2 (Wayland)
I just noticed this bug is opened since 2018... great.
For any of you having problems with Steam client HiDPI, here is a "hack" step-by-step while you wait for an official solution.
Basically, you'll set the environment variable GDK_SCALE. I'll be using 2 - because GNOME - so the variable will be GDK_SCALE=2. Is it pretty? No. Does it work? Yes.
Important
- When using GNOME, you either use 1:1 or 2:1 scaling, there is nothing in between.
- You may try to enable fractional scale, however, this is an experimental feature in GNOME. If you're curious:
- To enable fractional scale (again EXPERIMENTAL):
$ gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"- To reset the value:
gsettings reset org.gnome.mutter experimental-features
Tested on Fedora 32/GNOME 3.36.2 (Wayland):
- Make a copy of the steam.desktop file to the following location:
# cp /usr/share/applications/steam.desktop ~/.local/share/applications/
Note: The ~/.local/share/applications/steam.desktop will now take precedence over /usr/share/applications/steam.desktop so keep that in mind.
- Edit
~/.local/share/applications/steam.desktopwith an editor of your choice. Appendenv GDK_SCALE=2to theExec=parameter.
-
From this:
[Desktop Entry] Name=Steam Comment=Application for managing and playing games on Steam .... Exec=/usr/bin/steam %U .... -
To this:
[Desktop Entry] Name=Steam Comment=Application for managing and playing games on Steam .... Exec=env GDK_SCALE=2 /usr/bin/steam %U ....
Optional: change Name=Steam to Name=Steam HiDPI or something else for reference.
- Exit Steam client and start it again.
Now you may be able to read the screen.
If you want to revert the change, just delete ~/.local/share/applications/steam.desktop and you are good to go.
The hack @tiagomdrizzo @errotu mentioned above doesn't solve the issue at all! GDK_SCALE=1 is too small, but GDK_SCALE=2 is too large for me. The correct value I want is 1.25 or 1.5.
For any of you having problems with Steam client HiDPI, here is a "hack" step-by-step while you wait for an official solution.
Basically, you'll set the environment variable
GDK_SCALE. I'll be using2- because GNOME - so the variable will beGDK_SCALE=2. Is it pretty? No. Does it work? Yes.Important
* When using GNOME, you either use 1:1 or 2:1 scaling, there is nothing in between. * You may try to enable fractional scale, however, this is an experimental feature in GNOME. If you're curious: * To enable fractional scale (again **EXPERIMENTAL**): ``` $ gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" ``` * To reset the value: ``` gsettings reset org.gnome.mutter experimental-features ```Tested on Fedora 32/GNOME 3.36.2 (Wayland):
1. Make a copy of the steam.desktop file to the following location:# cp /usr/share/applications/steam.desktop ~/.local/share/applications/Note: The
~/.local/share/applications/steam.desktopwill now take precedence over/usr/share/applications/steam.desktopso keep that in mind.1. Edit `~/.local/share/applications/steam.desktop` with an editor of your choice. Append `env GDK_SCALE=2` to the `Exec=` parameter. * From this: ``` [Desktop Entry] Name=Steam Comment=Application for managing and playing games on Steam .... Exec=/usr/bin/steam %U .... ``` * To this: ``` [Desktop Entry] Name=Steam Comment=Application for managing and playing games on Steam .... Exec=env GDK_SCALE=2 /usr/bin/steam %U .... ```Optional: change
Name=SteamtoName=Steam HiDPIor something else for reference.1. Exit Steam client and start it again.Now you may be able to read the screen.
If you want to revert the change, just delete
~/.local/share/applications/steam.desktopand you are good to go.
That value has been repeated a number of times already and NO IT DOES NOT WORK! Please stop repeating what's already been said
Bug still present in Ubuntu 20.04, more than 2 years after it was reported.
- When using GNOME, you either use 1:1 or 2:1 scaling, there is nothing in between.
That's plain wrong... these days GNOME has enabled fractional scaling by default.
Workaround in https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-583857902 works well for me in Ubuntu 20.04.
- When using GNOME, you either use 1:1 or 2:1 scaling, there is nothing in between.
That's plain wrong... these days GNOME has enabled fractional scaling by default.
Not really, some distros tried it but reversed it since it was too buggy, there is no fractional scaling in gnome shell unless you are one of the few that runs wayland.
- When using GNOME, you either use 1:1 or 2:1 scaling, there is nothing in between.
That's plain wrong... these days GNOME has enabled fractional scaling by default.
Not really, some distros tried it but reversed it since it was too buggy, there is no fractional scaling in gnome shell unless you are one of the few that runs wayland.
I suggest you update yourself on the state of fractional scaling in the Linux Desktop, Wayland and GTK3 with Hi-DPI are the norm these days.
Unless you're one of those people running Gentoo on a text terminal, in which case you don't need the Steam Client, you just need to compile Dwarf Fortress.
- When using GNOME, you either use 1:1 or 2:1 scaling, there is nothing in between.
That's plain wrong... these days GNOME has enabled fractional scaling by default.
Not really, some distros tried it but reversed it since it was too buggy, there is no fractional scaling in gnome shell unless you are one of the few that runs wayland.
I suggest you update yourself on the state of fractional scaling in the Linux Desktop, Wayland and GTK3 with Hi-DPI are the norm these days.
Unless you're of those people running Gentoo on a text terminal, in which case you don't need the Steam Client, you just need to compile Dwarf Fortress.
Sarcasm aside you're either wrong or steam just doesn't play well with arch based distros like manjaro because I still have tiny text, can I suggest you switch to qt which seems to be popular these days and I've had no real issues with apps using that on manjaro, had to tweak global font defaults in the qt settings manager but otherwise no real issue with text
Sarcasm aside you're either wrong or steam just doesn't play well with arch based distros like manjaro because I still have tiny text, can I suggest you switch to qt which seems to be popular these days and I've had no real issues with apps using that on manjaro, had to tweak global font defaults in the qt settings manager but otherwise no real issue with text
I'm running an Ubuntu system with every app using HiDPI without any issues. Except for the Steam client that is. Thanks to the GDK_SCALE=2 trick mentioned above I've been able to make the Steam Client usable again.
The Steam client doesn't properly implement scaling and needs a work around. That's what this bug is about. And I hope Valve doesn't dismiss it with an excuse as lame as "it's not our fault".
Personally I'd rather steam did away with the "larger text based on screen size" option (which I've never seen work) and shove in a range box using the "pt" unit with minimum set to 6pt and maximum set to 100pt
Very nice. Works here on KDE Neon 18.04
I've tried all suggested fixes and options within the Steam Client. The UI is always too small or too large. There isn't a way for me to comfortably use Steam on my 1440p monitor, which is a common desktop size nowadays. Logging in on my old 4K monitor was nearly impossible. I hope Valve is aware of this. I find it hard to believe that none of the client's developers use high resolution monitors.
I have the same issue, I have Dell P2418D 2560x1440 display and Steam UI is just too small by default. Using GDK_SCALE is not a solution as in that case UI is too large. Checking an option to enlarge text and icons seemingly does nothing.
I had the same issue where checking the box to enlarge text was ignored and therefore Steam wouldn't scale. I'm on 4k resolution with fractional scaling at 1.25 in Gnome on Ubuntu 20.04.
Eventually I found out the issue is due to using an nVidia card and using nVidia proprietary drivers.. To fix the scaling issue with Steam, I had to use the X.Org X Server Nouveau drivers and use Wayland instead of X. In order to use Wayland with an nVidia card I had to make sure "WaylandEnable=false" was commented in /etc/gdm3/custom.conf as well as the following line was commented "DRIVER=="nvidia", RUN..." in /usr/lib/udev/rules.d/61-gdm.rules. After making those changes, restart, and you should be able to select Wayland from the gear icon at the login screen, which only appears after you click your username.
Problem now is that video performance is way down from using noveau drivers over proprietary.
I have two displays, but only my external display supports 4K (the laptop's display is 1080p). I found out Steam just scale automatically when the 4K display is the primary, that's consistent with thw system information gathered in Help > Sytem Information. Since I use my laptop's display as main display, I had to force scaling setting up the GDK_SCALE environment variable. Should be support two more than one display and do the scaling when one of (and not just the primary) displays support 4K.
This has been open for 3 years now. I'm on Linux Mint 20.1 Cinnamon with a 3440x1440 monitor with the scaling set to 125%. I just installed Steam and I can't read the fonts at all: ant-size text. Please up the priority of this and fix it.
You guys are already utilising css files WITH font-size used in them, just look for a file called user_styles.css in ~/.steam/ and then change all size references (font or not) to use rem, the user only has to set :root { font-size: #px } in user_styles.css then, it's not hard, boring and long to do but still easy enough, yes there will be the odd breakage of UX here and there, but they won't take long to fix if you focus on adaptive behavior instead of fixed, after all that's the WHOLE POINT of css as it is for the web
So I actually tried Gnome's fractional scaling today, on just one of my monitors, and it made STEAM SMALLER on ALL of my monitors.
I have 3x monitors, all in landscape 16:9. Left and Right are 1920x1080@60hz, middle is 1440@165hz.
All were previously 100% scaling, but then set the middle, 1440@165hz, monitor to 125% scaling. And suddenly STEAM is SMALLER on all three of the monitors. This is the exact opposite of what should happen!
This scaling really needs to be fixed, as STEAM is really bad for those of us with bad eyesight. I now can't use fractional scaling on that big monitor of mine because STEAM's so small, it's unusable! ARGH!
@kisak-valve can we get some recent VALVe response on this please?
@kisak-valve Why is this not fixed already? From my understanding (as a programmer) it is rather easy to set relative sizing for fonts, just set a global to start with, open ALL the project files into a text editor session and just do a global search for FONT_SIZE (I assume you at least avoided using custom names up until now), then make sure every single instance is getting the global variable prior to deciding the font size to use.
There seems to be a few separate problems. Writing here but maybe I should open a new issue?:
If you have a 4k and a non-4k screen (dual+ monitor), and have fractional scaling enabled, then Steam is so small that I actually cannot use it. I had to use my knowledge of where menu buttons are to be able to navigate at all. It's actually smaller than just 100% scaling at 4k. It's scaled to about 1/8 the size of my 4k screen.
Using the work around of setting env gdk_scale = 2 brings it back to a too small size (so the default 100% at 4k which is the too small font that is being complained about in this issue). I have to scale even more aggressively to get it to to be legible. Unplugging the 4k monitor and using just the 1440p monitor, or turning off fractional scaling, both "fix" one of the issues, in that now it's too small but I can work with it. Then I can set env gdk_scale = 2 at that stage, but then it's too big for the 1440p. Very strange and unintuitive behavior to say the least.
I can still confirm the problem is still here on Zorin 15.3 (Ubuntu 18.04)
Works like a champ (Pop OS 21.04)
Problem still happening.... Manjaro 21.1
Issue still happening, popOS 20.04
Issue still happening, Ubuntu 20.04.
Still exists, Ubuntu 21.10
I'm not a dev, but it can't be that this can't be solved. The other 200 companies can do it too. And Steam is just really not that small, or is it? Hmm...
If I have to guess they probably working on the new Steam client which would ship with Steam Deck, working both standalone and connected to TV, and would be running natively under Wayland. So I would not expect any fixes for current client.
If I have to guess they probably working on the new Steam client which would ship with Steam Deck, working both standalone and connected to TV, and would be running natively under Wayland. So I would not expect any fixes for current client.
lets hope so, this problem has already existed for more than 3 years...
still having issues. i can set it to 2.0x but then steam is literally so large it does not fit on my screen. if it was just really big, id deal with it, but i can't edit the settings because the "save" button is literally an inch off the bottom of my screen. same issue w/the main window.
the way it is is litterally hurting my eyes as i my eyesight is bad. i end up not wanting to run steam at all because it causes me pain to try to read the small print. its why i always increase the text size on all my machines.
would turning the HD stuff on my screen off help? i have a laptop, with the largest screen i could find: 17''
Works like a champ (Pop OS 21.04)
Issue is there in ubuntu 20.04 and 21.10 and Pop OS 20.04. Can you confirm that both issues mentioned in my comment are solved in Pop OS 21.04? Or specify which issue you don't see? It would help a lot in finding a workaround.
Works like a champ (Pop OS 21.04)
Issue is there in ubuntu 20.04 and 21.10 and Pop OS 20.04. Can you confirm that both issues mentioned in my comment are solved in Pop OS 21.04? Or specify which issue you don't see? It would help a lot in finding a workaround.
I already said how to fix it, stop using fixed sizes in your css and make sure all references to some sort of font size are relative to a global font size, no other way to fix it, to pretend otherwise is no different than an ostrich with it's head in the sand.
Edit: I know it's a lot of work but it's the only way to put the issue to rest permanently, having all font sizes relative to a single font size means you only have to change one size during boot, everything else will scale in proportion to that one change
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-976916318
Who are you talking to, @awsdert, who would be that "you"? @emirkmo doesn't seem to be a Steam employee. Maybe it would be more productive if you mention @kisak-valve or another Steam employee.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-977135070
I thought otherwise because of the way he spoke or rather typed, sounds like something an developer would've said so I just assumed he was
Just to be clear I have nothing to do with Valve. I'm just trying to solve it on my own end and was interested in a possible solution.
Since you guys like to insist on fixed sizes and css I have just the solution for this long standing issue, one I found just today, one of those "can't see the trees for the forest" things. Turns out css has a unit from CSS1 that honours DPI from the get go, 1in, now I find that particular size to be a tad too big for normal text but from my experiments 0.25in is about right, if you ditch the pixel unit and just use rem all over the place baring the root element for fixed size elements then everything will follow DPI properly if in the root element you use 0.25in or something near that size, always in inches, here's the test html/css I used to check it followed DPI:
<!doctype html>
<html>
<head>
<title>DPI Test</title>
</head>
<body>
<p style="font-size: 1.5in">DPI 1.5</p>
<p style="font-size: 1.25in">DPI 1.25</p>
<p style="font-size: 1in">DPI 1</p>
<p style="font-size: .75in">DPI .75</p>
<p style="font-size: .5in">DPI .5</p>
<p style="font-size: .25in">DPI .25</p>
</body>
</html>
Edit: Btw I did change my system DPI to see if these followed suit, they did
Edit 2: I believe the cm & mm units also follow the DPI but I didn't try them
This isn't a CSS issue, it's a scaling issue. In CSS, 1px is equal to 1/96 of 1in, not one screen "pixel". Changing units won't help if the density scaling factor is ignored in the first place.
This isn't a CSS issue, it's a scaling issue. In CSS,
1pxis equal to 1/96 of1in, not one screen "pixel". Changing units won't help if the density scaling factor is ignored in the first place.
You sure about that? You might wanna actually try the example I gave and change you're DPI settings with the example open, go on, I'll keep the tab open to see you take back your words :)
Edit: btw do you really think valve would be embed an in-house web object when there's plenty out there already? those undoubtedly read the DPI settings without issue, the main reason steam doesn't honour DPI at present is because of how they ignore the scalable CSS units in favour of pixels that never scale in the 1st place, this whole issue is a direct result of the unhealthy "pixel perfect" attitude companies & organisations have been applying to their websites, pixels never adapt to the user because pixels can be any size, only real world units will adapt to the user and inches/centimetres/millimetres are all units which depend on the DPI settings to emulate the real deal as closely as possible
There's nothing to take back, I expect that your example works well. Inches are an absolute length unit, as you say 🙂
The table "Absolute length units" in this page shows the relationship I mean:
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Values_and_units#:~:text=px,96th of 1in
Because px and in are defined in the same terms, switching from one to the other does nothing more than multiply or divide the size by 96. The issue here is deeper: whichever unit you use, Steam's renderer is not honoring (or perhaps not receiving) a separate multiplier, the screen density scale factor, when converting these units to real screen pixels.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-996230268
btw the in unit doesn't always map to 96px, that's just a typical setting as a direct result of common pixel size nowadays, as soon as pixel sizes get smaller that number is going to get bigger, and that's my point, doesn't matter how small the pixels become if you're tailoring the element sizes according to a unit that is powered by a DPI setting - btw I'm on linux also and changing font scale effects the DPI setting so in short yes the in unit WILL solve the problem since they insist on the bad design principle of "fix everything to one scale", they'll just be changing the unit they work with to one that follows DPI scale instead
btw the
inunit doesn't always map to96px
Yes it does, by definition.
https://www.w3.org/TR/css-values-4/#absolute-lengths
The spec's pretty clear on this in a lot of places. I think this px <-> in relationship would be a good place to run more experiments. If you find that some browser is acting against spec, maybe that should be its own issue! 😄
btw the
inunit doesn't always map to96pxYes it does, by definition. https://www.w3.org/TR/css-values-4/#absolute-lengths
The spec's pretty clear on this in a lot of places. I think this
px<->inrelationship would be a good place to run more experiments. If you find that some browser is acting against spec, maybe that should be its own issue! smile
No it doesn't:
absolute length units are fixed in relation to each other and anchored to some physical measurement
Note the words anchored to some physical measurement
That does not mean the measurement they anchor to cannot change, to be exact that measurement is the DPI, as evidenced by the results I had when I changed the DPI with the example I gave open.
The absolute length units are fixed in relation to each other...
1px = 1/96th of 1in
These are both in the spec just below where I linked, verbatim. I don't see any room for interpretation. 🤷
I think we're talking past each other, sorry. Your example works as described, of course. The problem is that px will also behave that way: render a 1px line on a high-DPI screen and you may see that it's 2 or 3 physical pixels wide. Switching from px to in only makes the unit 96 times bigger. It doesn't change its scaling behavior, because px are already density-independent.
Was about to say "No, pixels don't stretch, they're at a 1:1 ratio with the resolution setting" but then decided to actually try it, rather strange that the pixels don't obey the resolution, well in either case they shouldn't be using pixels all over the place, :root element only, anywhere else is bad form, instead everywhere else should use rem allowing for easy change of just the :root element's scale which would then seamlessly propagate throughout the interface. As for ignoring DPI I can only think that besides the constant usage of a unit that should ONLY be used in the :root element, the other cause can only be using an in-house web control (assuming they use one), to fix that I can only think to maybe branch luakit then just customise some UI's via lua, much harder for security breaches to happen via javascript if the client is using a separate language, not impossible just harder, also harder to mix up scripts meant for different UIs, I'm certain luakit honours DPI already and I would not be surprised to find that everything inside the steam window is just embedded web stuff, would explain why dialogues seem to follow DPI yet the interface that matters most doesn't. If they're going to insist on lazy design (which to be fair is kinda expected in this scenario) then they should at least outsource things they shouldn't be doing in-house solutions for in the 1st place, they already out-house part of proton to wine, why not the web control to luakit or some other open source browser which undoubtedly has it's own web control
Edit: Also the in, cm & mm units are all much clearer in what size they're supposed to emulate and will give consistent results regardless of platform, pixels and other units are less clear, although some are arguably better choices for a UI, in all cases "pixel perfect" is the worst choice one can make for UX, it literally screams "I'm out of touch"
I am on Fedora 35 running Steam with flatpak and managed to fix it by running the following command to set the GDK_SCALE environment variable.
sudo flatpak override --env=GDK_SCALE=2 com.valvesoftware.Steam
We've come across an issue on SDL's end that might indicate that, at least in the Wayland scenario, this is a compositor issue... we recently added support for xdg_output to try and support fractional scaling in the upcoming SDL 2.0.22 release, and discovered that while the desktop stores the correct scale factor, it does not convey this information where it should:
https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandvideo.c#L310-L325
This impacts the Xwayland scenario because from what I understand they also use this mechanism to determine scale (like we did until this block was added). The result is that some things will scale while others won't depending on which scale you look at, and that's what I've been seeing in the Steam client on GNOME recently.
Glad to see someone's working on the issue,
Edit: Would be more helpful if you added the option to ignore the system scale and use steam scale setting instead, that same setting can then be used as the fallback and the usage of system disabled if it is detected to be buggy. Alternatively just do
this:
char const *GTK_SCALE = getenv("GTK_SCALE");
float scale = 1.0f;
if ( GTK_SCALE )
sscanf( GTK_SCALE, "%f", &scale );
if ( scale <= 0.0f )
scale = 1.0f;
driverdata->scale_factor = scale;
There's no particular reason you HAVE to rely on SDL to get the info if you already know about the variable to begin with
In my case I'm running kubuntu 22.04 on x11 sessions. Issue occurs after using xrandr to scale down the main display but not the rest of the displays.
ie. I run: xrandr --output eDP --scale .5 --filter nearest and this lets me dock without having tiny apps on my main display but normal size on other displays. Otherwise KDE scaling options are global for all displays so that's why I need to use this method. I think that's what is confusing steam. So steam is so large it doesn't even fit on the screen until I run steam with GDK_SCALE=1 ... in my steam.desktop file. A pretty simple fix but... also pretty unfortunate it seems to only need to be done for steam.
Let me know if I can help with any more info :)!
Still happening on Mint 21. The GDK_SCALE=2 setting doesn't work at all, not from the terminal nor changing the Steam launcher file thingy. That may be a Mint issue, or an issue with the Cinnamon DE.
Issue still persist for me on latest Steam beta. Four years passed.
"GDK_SCALE=2" is too big, but "GDK_SCALE=1" is too smal to read.. Would be great to at least get a possibility to set 1.25 or 1.5
Absolutely incredible
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-1195668696
I see similar issues with e.g Zoom screen scaring if the primary display is scaled down but not the secondary. Good catch. Actually nowadays I just set my primary to 4k 1to1 scale and live with it, zooming in for text and stuff..
Holy f*ck it's still there after all these years...
GDK_SCALE=2 makes it too big. it's unusable.
without gdk scale variable, interface setting for big text does nothing.
100% scaling at 1080p is just so miniscule that it's beyond usable
hi-dpi skins are broken. everything gets scrambled
it's not foss so you as a user can't do anything about it. just great
At this point, I would take too big. GDK_SCALE=2 isn't doing anything in Ubuntu 22.04, everything is tiny no matter what I do.
@kisak-valve IMHO, this should not be labeled as Feature Request but rather a bug. Because big picture mode can play nicely with the system.
Since we're coming up on the 5 year anniversary of this bug not being fixed, I'm wondering if it's been OBE by the Steam Deck? Are we no longer supposed to install the Steam linux client on linux systems? Are we somehow supposed to install just the UI portion of the Steam Deck instead?
They also don't care much about Steam OS. It makes me wonder what do they even care about
Such a half-assed attempt at Linux, Valve. Not even respecting the toolkit's scaling settings? what kind of sorry integration attempt is this? When 4K monitors are standard across the board, what are your users going to do? get a magnifying glass to use your client? GDK_SCALE is a hack that will eventally not work anymore, you need to fix this.
Read this whole issue after suffering here myself with the same thing. Would love to be able to fix this myself, but I am left to use the GDK_SCALE hack. I still can't believe there has been zero movement on this issue after all these years.
This is not a feature request!
Steam is unusable for many because of this issue.
I am on beta (build Feb 24 2023, 01:01:00) and it got broken recently. Previously the "Enlarge text and icons..." was working somewhat ok, it was at least consistent. After recent update (a week back?), everything except top bars is tiny (again, it was broken like half year back but was fixed). The GDK_SCALE settings seems to be respected only for top bar, it's pretty terrible now (looks pretty similar/barely usable with and without the "Enlarge..." option; scaling is set to 3 here):
This is ~20% of my small 4k screen, I can barely read names of games...
After switching to wayland and enabling the experimental fractional scaling, everything works now. Even steam albeit little blurry
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"
Note: Enabling fractional scaling can result in blur for legacy applications using XWayland, even if only integer scales are used, because the rendering method changes.
Why didn't anybody mention that GDK_SCALE workaround also causes all the windows spawned from Steam, such as games or web browser in case I click on a link in Steam client, to inherit the scaling option and render at double the resolution? This workaround is pointless if I still have to change scale back to 100% before launching any game so it doesn't assume my monitor is double it's size.
I've checked this here on KDE NEON 22.04. With an without "GDK_SCALE workaround" games have the same size. Tested with:
- The Greatest Penguin
- Dying Light2
- Rise of the Tomb Raider
I haven't noticed this kind of behavior in any game in recent years either.
Wasn't that fixed with latest steam beta client?
Wasn't that fixed with latest steam beta client?
Don't know. I never had this behavior.
What do people say? PRAISE GABEN
There is finally a fix!
The beta has fixes for this extremely long standing issue, go and give it a try!
https://store.steampowered.com/news/group/4397053/view/3705943193607193985?l=english
After last BETA update steam does not start anymore. After i have installed steam comletly new, same result. No start anymore with actual BETA. No Error message.
According to the notes:
Steam will now use the system's global scale factor as configured in KDE/Gnome settings. Specifically org.gnome.desktop.interface/text-scaling-factor.
Isn't that the wrong value? Shouldn't it be scaling-factor not text-scaling-factor?
@kj neither property works for me, nor does the -forcedesktopscaling flag or $GDK_SCALE. I don't know what else to try. Using i3wm (X) with NVIDIA on Arch Linux.
The -forcedesktopscaling flag does work for me under Gnome Wayland (in Sway it just results in an oversized UI, but it does 'work').
Actually, I'm not even sure that the scaling-factor setting is correct either, as it's set to 0 for me, although my display uses 200% scaling (the value in Gnome Settings is per-display anyway, not global). That might just be a Wayland thing and perhaps this Steam update is only trying to solve the issue for X.org (as Steam doesn't support Wayland yet). To be honest I don't know exactly how this is supposed to be solved, but text-scaling-factor seems wrong to me and I hope that whatever we end up with just integrates nicely with desktop standards.
If it helps, I'm on a Ryzen 5825U (AMD graphics).
@kj neither property works for me, nor does the
-forcedesktopscalingflag or$GDK_SCALE. I don't know what else to try. Using i3wm (X) with NVIDIA on Arch Linux.
I confirm. Running ubuntu 23.04 and Nvidia drivers on X. both feature are not working for me (neither combined together)
This is wretched. It worked fine before today's update and now it refuses to respect any scaling settings, with all the text absolutely tiny. Nvidia GPU using binary drivers, Arch Linux running XFCE on X11.
Same problem with the new steam update with Nobara Linux kernel 6.3.7-200 on GNOME 44
Some additional information: resolved by adding -forcedesktopscaling 2.0 to the flatpak launch
Issue happens in x11 only and not wayland, but I can't use wayland
Yep, they went out of beta and full release without having UI scaling sorted out. Worked before the update, UI is tiny now on stable.
Wayland user here. -forcedesktopscaling 2.0 is working for me. Side feedback: hate the new UI, miss mid 2000s UI, only needed scaling and GPU acceleration.
Edit: Just add a multiplier to the Settings menu already, Steam's “decision” regarding size requires overriding sometimes, especially in my case. Sucks to have to continue to modify .desktop files or shell scripts to keep adding -forcedesktopscaling 2.0 to everything.
Holy *@$% I opened steam and I can't read ANYTHING. Why isn't there just a drop down to set this higher?
Edit: GDK_SCALE seemed to do nothing, but -forcedesktopscaling 1.8 worked out for me.
Pretty confident it'll get overwritten with each major update though.
Holy *@$% I opened steam and I can't read ANYTHING. Why isn't there just a drop down to set this higher? Edit: GDK_SCALE seemed to do nothing, but
-forcedesktopscaling 1.8worked out for me. Pretty confident it'll get overwritten with each major update though.
That was exactly my problem. I can read size 6 font even, but it was just horribly difficult to use my mouse to access the menu (there are no accelerators, what the ...) and attempt to toggle that bool which did nothing (must be some goofy math going on, just a missed situation I'm guessing). The ability to specify a float multiplier for DPI should have definitely been in a beta at least... The ability to access things with the tab key would increase user accessibility, but who knows if that'll ever come to fruition, they're using a web browser as a client ffs. I wish Chromium had never been made, all this HTML as an app is just infuriating. Native controls, people!
That was exactly my problem. I can read size 6 font even, but it was just horribly difficult to use my mouse to access the menu (there are no accelerators, what the ...) and attempt to toggle that bool which did nothing (must be some goofy math going on, just a missed situation I'm guessing). The ability to specify a float multiplier for DPI should have definitely been in a beta at least... The ability to access things with the tab key would increase user accessibility, but who knows if that'll ever come to fruition, they're using a web browser as a client ffs. I wish Chromium had never been made, all this HTML as an app is just infuriating. Native controls, people!
Discord has tab controls. Pretty confident it can be done. Just a matter of them wanting to implement it.
Discord has tab controls. Pretty confident it can be done. Just a matter of them wanting to implement it.
True, but it's still web pages masquerading as software. As someone developing since 2004, I have a disdain for fake 'apps' (I hate the word app, as well. Hardware, Firmware, Kernels, Drivers, Software)
i3wm, AMD GPU, Manjaro and after today's update I got tiny everything again. I'll have to test more, but GDK_SCALE set to 2 seems to work.
True, but it's still web pages masquerading as software. As someone developing since 2004, I have a disdain for fake 'apps' (I hate the word app, as well. Hardware, Firmware, Kernels, Drivers, Software)
Yeah, I would prefer native everything too (maybe a bit strange, since I am a front-end dev). On the other hand for an end user this hybrid approach might be better - more features and support of less common OSes like Linux, paid with disk space, memory and cpu cycles. It's a trade off in both cases (considering we run Linux) and at least for those with more powerful PCs, this very well could be the better option.
You can correct all of this problems of the last version, with this command:
steam -forcedesktopscaling 2
You can correct all of this problems of the last version, with this command:
steam -forcedesktopscaling 2
Found the person that didn't read. We know this already. That's just a patch-job and a nuisance at best. It needs integration in Settings already, ffs. This issue has been going on since 2018 at least.
Edit: Why Valve chose Gnome over something else such as Qt, I'll never know. Gnome's an accessibility & user-control nightmare. My guess is licensing, which I'd grant considering Qt's got some fucked up licensing.
Lots of reports/complaints here with no hardware details, if you purchased an nvidia card admit it
@mnn It might be better to use the new STEAM_FORCE_DESKTOPUI_SCALING env var to adjust scaling, as GDK_SCALE can affect other things.
How were you previously configuring your scaling settings? We stopped querying org.gnome.desktop.interface text-scaling-factor outside of KDE, because gnome and KDE interpret it differently. The former uses it for text specific scaling. The latter stores its global scale factor there.
Lots of reports/complaints here with no hardware details, if you purchased an nvidia card admit it
Pure AMD. I don't touch Nvidia or Intel. amdgpu and sometimes amdvlk, neither is a problem for DPI, it's only Steam. Hardware details aren't necessary if it's just Steam doing this.
How were you previously configuring your scaling settings? We stopped querying
org.gnome.desktop.interface text-scaling-factoroutside of KDE, because gnome and KDE interpret it differently. The former uses it for text specific scaling. The latter stores its global scale factor there.
That text-scaling-factor doesn't work for me on KDE, but I don't use ancient Xorg, just Wayland. Tired of hanging on to old software that keeps everyone back. :/
STEAM_FORCE_DESKTOPUI_SCALING
is there a similar env var for the overlay? even when steam launches properly at 100%, the overlay keeps going to 200%
on a high DPI monitor (large 4k screen) the overlay is super cumbersome, feels like I got the "Fisher Price" version of Steam running
With
forcedesktopscaling 2
it works here on KDE Plasma, but with a lot strange of CPU usage, because the mouspointer hangs again and again during normal working. Without scaling, normal usage.
Funny reading all those comments. I'm on a 27" 4K screen, but for me it's the other way around. Steam does increase text size by default (WAY too big for my taste), but not the other UI elements. So when I click on a menu only half of the text./menu items fit inside the menu box, the rest is unaccessible. I have to use -forcedesktopscaling 1 to be able to use Steam now. Disabling "Scale text and icons to match monitor settings" doesn't do anything.
Hello @Arumes, your screenshot is showing #9708. Opt into Steam's client beta.
@kisak-valve An exposed float in the Settings of Steam so that we can specify our own factor, for Windows and Linux, to give us manual control, might be best..
I had the same here, but here was helped the automated scaling. But on the stable version of the steamclient. Resolution 5120*1440
New nice thing. Since scaling is activated, i often get this after unlock the screen. Crazy...
... and the windows can not be closed without exiting steam....
I still see this issue with the latest steam beta version. forcedesktopscaling 2 is working for me but I would prefer steam to detect the correct desktop scale by itself since I already set it to 200% in Ubuntu settings. I am using Wayland so Steam is running in XWayland.
See also this report: https://github.com/ValveSoftware/steam-for-linux/issues/9209
Since Steam can (in principle) already use the GNOME setting, I suggest closing this issue here, and following the other one.
The current issue seems Linux wide, on any environment.
See also this report: #9209
Since Steam can (in principle) already use the GNOME setting, I suggest closing this issue here, and following the other one.
The current issue seems Linux wide, on any environment.
Why would you close the issue? It's unresolved! The client just needs to expose a float/double multiplier for DPI. Let the user choose!
Valve is a great company, they do amazing things... I can't fathom why after years and years, text scaling doesn't work in their client. While I admit I couldn't fix it myself, it can't be rocket surgery. I wonder if it has something to do with presenting products of companies, like if someone made the fonts look too big it would "deface" the product? I don't understand it.
Nevermind, -forcedesktopscaling 1.3 works for me. Cheers!
(I'm in KDE.)
Why would you close the issue? It's unresolved! The client just needs to expose a float/double multiplier for DPI. Let the user choose!
Did you see the issue, that I linked? As far as I know, is the original issue resolved, and a new one appeared. That one is cared for in this link.
Any objections?
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-1832650057
What are you talking about? This issue still exists. Steam is not using Gnome's scaling or any desktop scaling correctly (if at all). I'm forced to use STEAM_FORCE_DESKTOPUI_SCALING. The other Issue is newer than this one and they're requesting the same fix as this Issue should have. A bloody float ("slider") to specify a multiplier.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-1832778758
In this instance... while I understand your wish your a UI element, the proper "bug fix" would be to properly detect system settings. A feature request for the UI element to scale is another issue (one I think would be nice, but is beside the point.)
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-1832785658
System settings will never be right for those that want Steam a certain size aside from the system. Even when I do go out of my way to override Gnome, Steam still doesn't scale. Original Issue still exists, and an easy fix is exactly what me and others have asked for, a way to specify our own size. That'd work across any Desktop Environment. >\
System settings will never be right for those that want Steam a certain size aside from the system. Even when I do go out of my way to override Gnome, Steam still doesn't scale. Original Issue still exists, and an easy fix is exactly what me and others have asked for, a way to specify our own size. That'd work across any Desktop Environment. >\
And again, from a software development standpoint, that is a feature request. Not a bug report.
System settings will never be right for those that want Steam a certain size aside from the system. Even when I do go out of my way to override Gnome, Steam still doesn't scale. Original Issue still exists, and an easy fix is exactly what me and others have asked for, a way to specify our own size. That'd work across any Desktop Environment. >\
And again, from a software development standpoint, that is a feature request. Not a bug report.
And again, Steam isn't using Gnome's settings that I've forcibly overridden because even Gnome gets it wrong, so this Issue still stands, regardless of 'a feature request'. Gnome softwares do what I've told them to, Steam isn't using Gnome.
even Gnome gets it wrong, so this Issue still stands, regardless of 'a feature request'. Gnome softwares do what I've told them to, Steam isn't using Gnome.
even Gnome gets it wrong, so this Issue still stands, regardless of 'a feature request'. Gnome softwares do what I've told them to, Steam isn't using Gnome.
Translation for non-devs: "Suck our software."
Translation for non-devs: "Suck our software."
I'm trying to impress upon you that, when a team of developers is working on a complex software project, you don't add band-aid features to "work around" bugs before solving the bug. I am sure whoever at Valve reads these issue reports from end-users are aware of the problem; suggesting a slider is a great idea, but not one that is automatically adopted because you think it would "solve everything." When you write your large software distribution platform, you can include a DPI slider. 😊
Translation for non-devs: "Suck our software."
I'm trying to impress upon you that, when a team of developers is working on a complex software project, you don't add band-aid features to "work around" bugs before solving the bug. I am sure whoever at Valve reads these issue reports from end-users are aware of the problem; suggesting a slider is a great idea, but not one that is automatically adopted because you think it would "solve everything." When you write your large software distribution platform, you can include a DPI slider. 😊
Not a bandage, an actual necessary "feature" eventually which would address your Issue in the meanwhile. Fixing #9209 or 'closing' #5460 won't address the issue of user DPI, only "we guess this DPI for you". If any DE can't get it perfect neither will you, even if you listen to them. Users may want 2.0 for environment, 1.5 for Steam, for accessibility, it's tied into your approach to resolving all this. Add an exposed float and we can choose for ourselves, no need to even use the DE in that case, Issue can be solved that way, too. I adopted DPI into my development practices before SteamOS was even a thing, I've dealt with accessibility issues and found so many could be solved while fixing other issues and that many times an accessibility-oriented approach solved them.
Not a bandage, an actual necessary "feature" eventually which would address your Issue in the meanwhile. Fixing #9209 or 'closing' #5460 won't address the issue of user DPI, only "we guess this DPI for you".
If a proper fix is made, it won't be "guessing", it will be respecting the user's choice of display scaling at the DE level.
If any DE can't get it perfect neither will you, even if you listen to them. Users may want 2.0 for environment, 1.5 for Steam, for accessibility, it's tied into your approach to resolving all this. Add an exposed float and we can choose for ourselves, no need to even use the DE in that case,
Most applications do not provide a scaling slider, since it just creates two sources of truth for scaling settings. You can already manually modify the scale of the app using command line arguments, so the feature you request is available already.
Issue can be solved that way, too. I adopted DPI into my development practices before SteamOS was even a thing, I've dealt with accessibility issues and found so many could be solved while fixing other issues and that many times an accessibility-oriented approach solved them.
I think this thread should be used for discussion related to the bug only, and a separate issue should be created for a request such as this.
What should be worked on first and foremost is fixing Steam's lack of awareness for Gnome's scaling. I disagree with the label of "Feature Request" (unless I'm misinterpreting the issue) and I feel that this is more of a bug, since other environments respect the chosen scaling of the user.
If a proper fix is made, it won't be "guessing", it will be respecting the user's choice of display scaling at the DE level.
If Gnome can't get it right guessing and sometimes individual software needs scaling for specific reasons...no, you can't rely on it. Implement it if you want as a default, but the user should have final say to choose. No one wants to set their entire system to a different DPI just to affect one application that may not look the way they want/need even following DE.
Most applications do not provide a scaling slider, since it just creates two sources of truth for scaling settings.
Many do, even if it's only font-size. The year is 2023, not < 2010. More and more have begun to implement it. So many new screen sizes, so many different devices, so many pixels-to-display ratios and top that off with user preferences and disabilities...
You can already manually modify the scale of the app using command line arguments, so the feature you request is available already.
No one wants to memorize environmental variables for something that should be integrated for the various reasons I've mentioned. The feature requested was a means of specifying DPI via GUI.
What should be worked on first and foremost is fixing Steam's lack of awareness for Gnome's scaling. I disagree with the label of "Feature Request" (unless I'm misinterpreting the issue) and I feel that this is more of a bug, since other environments respect the chosen scaling of the user.
You can't ever guarantee the desired DPI. Some people prefer the application to be bigger or smaller than DE choice. You can default to it, but the ability for a user to specify their own size (you know, like most modern video games?) is pretty much universally desired.
I think this thread should be used for discussion related to the bug only, and a separate issue should be created for a request such as this.
Go for it, I don't care anymore. It seems I'll always be forced to use an *obscure environmental variable (if that even remains constant and available) to set Steam's DPI anyway. Even if Steam did respect Gnome, Gnome is wrong anyway and some software look worse with DE settings and need manual tweaking.
I find it somewhat amusing Steam is a platform based around games and games are known to have accessibility issues...which need user-specific overrides, but the whole approach here about 'suck off, we're going to use Gnome's setting and not let you individually scale Steam except through some obscure means unlike modern software' seems a bit tone-deaf. See what I did there, tone-deaf? No need to reply.
Edit: *A random-ass environmental variable you won't know the name of until you actually resort to search-engines to find the name of and hope you have access to the operating system or permissions to be able to set for whatever reason such as disabilities.
This issue is about GNOME's scaling setting, or respecting the desktop environment. A DPI slider has nothing to do with that. You can argue your case for such a feature in a separate issue and stop derailing this one.
This issue is about GNOME's scaling setting, or respecting the desktop environment. A DPI slider has nothing to do with that. You can argue your case for such a feature in a separate issue and stop derailing this one.
I wasn't derailing it, I was proposing a workaround for this bug's effect, a workaround that would at least allow users the ability to use Steam and solve future issues of 'I want Steam larger/smaller than my DE DPI'. But no worries of 'derailing', I unsubscribed earlier and merely thought I should add earlier's tidbit about the absolutely obscure workaround (for this bug [aka relevant] and of DPI in general) of an environmental variable that no one's going to know about.
It's just that you're spending an awful lot of words and energy in a very loosely related thread when you could be opening a new issue where you have all the luxury of framing it as an accessibility issue/feature and discussion can focus on that. The way you're presenting it in this thread is almost as if it's a replacement for proper scaling based on a global setting, so of course you're going to go up against resistance. Those of us who want this fixed don't want a workaround, we want it fixed. You claim that your idea is a necessary feature for accessibility, so open a feature request where that can be discussed on its own merits.
Plasma on Ubuntu here, running steam:i386 from apt. In order to get the command line argument set, I had to edit /usr/games/steam, which is a shell script ... which calls a shell script? Anyway, changed line 110 from:
test -x "$STEAMDIR/steam.sh" && exec "$STEAMDIR/steam.sh" -nominidumps -nobreakpad "$@"
To:
test -x "$STEAMDIR/steam.sh" && exec "$STEAMDIR/steam.sh" -nominidumps -nobreakpad -forcedesktopscaling 1.5 "$@"
I have Display Configuration > Global scale set to 150%. I think this system was originally Ubuntu 08.04 and has been upgraded over the years. Everything worked fine in Steam until a few years ago, when it one day switched to tiny fonts? Anyway, I am happier for now, until /usr/games/steam gets updated, I guess.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/5460#issuecomment-1871775927
OMG, that's it. Waiting for years... but you are the Saviour :1st_place_medal:
... works perfectly here on KDE NEON.
Installed Steam through the deb file on Kubuntu 23.10. Using @dannyman's fix, I had to modify /usr/bin/steam/bin_steam.sh on line 216. /usr/games/steam isn't present, don't know if that has to do with my install approach or not.
exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" "$@"
->
exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" -forcedesktopscaling 1.5 "$@"
Just curious, is there a reason you guys are editing the shell script that steam installs to invoke itself, rather than just editing the menu entry/.desktop file or whatever you're using to call it?
Just curious, is there a reason you guys are editing the shell script that steam installs to invoke itself, rather than just editing the menu entry/.desktop file or whatever you're using to call it?
I am not relying on editing the desktop file or whatever it is called because that doesn't work. I don't know if the wrapper script is trying to capture and pass command line args or not, but in my efforts to get things working, I found that invoking /usr/bin/steam -forcedesktopscaling 1.5 did not result in a scaled UI and what I had to do was hack the wrapper script itself. 🤷🏻
Just curious, is there a reason you guys are editing the shell script that steam installs to invoke itself, rather than just editing the menu entry/.desktop file or whatever you're using to call it?
Uhhhh because I don't know what I'm doing and I assumed it wouldn't work since appending the option to steam on the command line didn't work :)
@dannyman @JamesNKing Alright, fair enough! Works for me in KDE, but do what ya gotta, I guess.
Deleting the change from /usr/lib/steam/bin_steam.sh and adding it to the desktop file seems to have retained the desired scaling effect. Not sure if that's Steam maintaining the old setting it was provided or properly reading the updated one.
FWIW, I got it working by executing
sudo flatpak override --env=STEAM_FORCE_DESKTOPUI_SCALING=2.0 com.valvesoftware.Steam
in any console. You dont need to modify your .desktop file which is a nice touch! This only works for the flatpak version, of course.
If you use flatpak, you can set it once and for all using something like Flatseal:
If you use flatpak, you can set it once and for all using something like Flatseal:
Thanks, this worked!
On Fedora 39 KDE open /usr/lib/steam/bin_steam.sh edit line 179 from exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" "$@" to exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" -forcedesktopscaling 1.5 "$@" the 1.5 can be adjusted to the scaling that the desktop is using.
I think i have to use this because i also have to force steam to default to the non preferred GPU (iGPU).
what worked for me, instead of setting that variable and config (which I didn't try as this was the first thing that worked) was simply toggling "scale text and icons to match monitor settings" from the interface in settings, off and then on and restarting steam both times. If that doesn't work, you should do what others have suggested on here.
This has been open since 2018, and it is still a problem. I'm using Fedora 40 (tried both Gnome/Wayland and Cinnamon), and installed Steam from the software store.
Passing arguments from the application menu does nothing. Having to manually go in and adjust configuration files just to make this usable is unacceptable.
You get what you paid for :) . Also why complain about stability and run Fedora?
You get what you paid for :) . Also why complain about stability and run Fedora?
Yes, I'm paying Valve via the games I purchase. I'd submit a ticket in Steam itself, but that system has its own problems that are secondary to this.
And apparently, this isn't even contained to any particular distribution, as evidenced by the users above me. This isn't even a stability question to begin with, it's an oversight, and we get the same answer from the devs every time: "Deal with it lol"
I literally cannot read the screen. I had to pull out a magnifying glass just to find where "Settings" was in the menu.
"Steam only officially supports Ubuntu running Ubuntu 12.04 LTS or newer and SteamOS, but the Steam for Linux community is extremely resourceful and has managed to run Steam on a large variety of distros. Valve approves of these efforts but does not officially endorse or provide support for them. Steam on Linux supports both x86 and x64, it's highly recommended that you ship 64 bit binaries as the vast majority of users will be running that."
Passing arguments from the application menu does nothing. Having to manually go in and adjust configuration files just to make this usable is unacceptable.
If you're on kde, its pretty simple. You don't have to go into any configuration files. Open the search menu, type steam -> right click on steam (runtime) -> edit applications -> go to 'Application' tab -> Put this in your "Arguments:" section:
"-forcedesktopscaling=1.5 %U" (without the quotation marks)
Change 1.5 to whatever scaling you have set your display as. If its 200%, set it to 2.0 and you're done. It's foolproof and simple.
Just tried to set up GDK_SCALE=2 as a Environment Variable, and then restarted Plasma 6 which is set to 200% in display settings. The results are... something (Obsidian scales to 400%, Steam stays at 100%, and all I wanted was for both to be at 200%):
So it seems that, at least Electron apps, scale once for the desktop setting, and again for the GDK_SCALE=2 variable. But Steam doesn't, for neither of them.
So, for now, I'm going back to disabling the GDK_SCALE=2 environment variable, and enabling the STEAM_FORCE_DESKTOPUI_SCALING=2.0 one. It sucks that Steam isn't able to read this value.
I am seeing this issue on KDE Plasma on a hidpi monitor with scaling set to 150%.
If I set STEAM_FORCE_DESKTOPUI_SCALING=1.5, the scaling is correct. If I launch big picture and then exit back to the normal steam interface, the scaling is correct. However, if I set STEAM_FORCE_DESKTOPUI_SCALING=1.5 and enter big picture and then exit back to the normal interface, the scaling is applied twice.
So something about entering and exiting big picture triggers the correct scaling without any additional environment variables.
As of today's beta, steam will now query the scaling setting value via SDL3. We've been working with various DE devs to ensure that their DE reports the right value via SDL3 for both wayland and X11 based systems.
The main reason for this change is that there is a myriad of ways scaling settings are stored and trying to keep up to date with this logic in the closed source steam codebase is an uphill battle. Now, if there is a case where we are getting the wrong data via SDL3 the relevant DE devs can inspect the code and provide upstream patches to SDL to address the issue.
Please note the following caveats:
STEAM_FORCE_DESKTOPUI_SCALINGand-forcedesktopscalingtake precedence over the SDL3 query. So if you have made any changes to your environment to set these, you might need to remove them to take advantage of the new logic.- We query the scaling settings for the primary monitor.
- Scaling does not automatically change when a window moves to a different monitor with different scaling settings.
I disabled (unset / removed) STEAM_FORCE_DESKTOPUI_SCALING and updated my Steam client to:
Steam Beta Branch: Steam Families Beta
Steam Version: 1722028579
Steam Client Build Date: Fri, Jul 26 22:54 UTC -08:00
Steam Web Build Date: Fri, Jul 26 22:54 UTC -08:00
Steam API Version: SteamClient021
However, scaling does not appear to be applied in Steam -- the text is tiny. My primary screen is scaled at 175% and the 2nd screen at 125%, see also Window Manager info linked below.
System:
Operating System: NixOS 24.05
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.2
Kernel Version: 6.10.0 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics
Memory: 30,6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Window manager: https://invent.kde.org/-/snippets/3190
@devurandom A good place to start with that report might be with the NixOS steam package maintainers.
Currently the whole logic in steam amounts to pretty much two function calls (with a bit more error handling in between):
SDL_InitSubSystem( SDL_INIT_VIDEO );
float flScale = SDL_GetDisplayContentScale( SDL_GetPrimaryDisplay() );
So bugs will most likely be in either distro or SDL. Since NixOS tends to be fairly different from other distributions it might be best to check with the NixOS steam package maintainers first.
I run Steam as a Flatpak. Could that be a problem for this mechanism of getting the scaling factor?
Doesn't work here, yet. Fedora 40, Plasma 6, Wayland.
I tried a small simple SDL3 program with the function posted (C++), and it succesfully outputs 2.0 as the float value, so at least the DE and SDL3 are correctly informing the value.
Hopefully next beta version will have the update in place.
Steam Beta Branch: Steam Beta Update
Steam Version: 1722028579
Steam Client Build Date: Fri, Jul 26 4:54 PM UTC -08:00
Steam Web Build Date: Fri, Jul 26 4:54 PM UTC -08:00
Steam API Version: SteamClient021
Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.9.11-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 31,0 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX
Manufacturer: ASUS
@devurandom Flatpak could make a difference, but I tested flatpak on my system (Arch+KDE+wayland) and it worked okay. It is probably still a good idea to test the non-flatpak version of steam on your distro.
@perroboc You need to make sure you run the test app in the same environment as Steam runs in. That includes making sure it is compiled in 32bit mode and running it inside the steam runtime. And make sure you are using SDL3, most distros ship SDL2 at the moment. Additionally, Fedora has non-standard modifications to SDL, which include changing the default SDL backend to wayland. So you'll need to add SDL_VIDEODRIVER=x11 when launching the app. There might be other details here too depending on how your distro launches steam.
I can add some extra logging to dump the scaling information we read to help understand if it is an issue on the steam side or the distro side.
make sure you are using SDL3, most distros ship SDL2 at the moment
Can confirm I wasn't able to find SDL3 in the Fedora repos (while SDL and SDL2 were available, SDL3 had to be downloaded from source repo for my poc test). Pretty sure this is why it's not detected.
you'll need to add
SDL_VIDEODRIVER=x11when launching the app
Even with this env var it wouldn't detect the DE scale.
I can add some extra logging to dump the scaling information we read to help understand if it is an issue on the steam side or the distro side.
I agree this would be great to have (and help)! Maybe when launching with --verbose. I wasn't able to find if I was using SDL2 or SDL3, for example.
I did cd ~/.steam/root/ubuntu12_32 and file * | grep ELF | cut -d: -f1 | LD_LIBRARY_PATH=. xargs ldd | less and searched for SDL3, and came up with the following:
friendsui.so:
libSDL3.so.0 => ./libSDL3.so.0 (0xf765c000)
gameoverlayui.so:
libSDL3.so.0 => ./libSDL3.so.0 (0xf7606000)
libSDL3_image.so.0:
linux-gate.so.1 (0xf7f38000)
libSDL3.so.0 => ./libSDL3.so.0 (0xf7c70000)
libc.so.6 => /lib/libc.so.6 (0xf7a5a000)
libdl.so.2 => /lib/libdl.so.2 (0xf7a55000)
librt.so.1 => /lib/librt.so.1 (0xf7a50000)
/lib/ld-linux.so.2 (0xf7f3a000)
libm.so.6 => /lib/libm.so.6 (0xf797b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7976000)
libSDL3.so.0:
linux-gate.so.1 (0xf7f26000)
libdl.so.2 => /lib/libdl.so.2 (0xf7c7d000)
librt.so.1 => /lib/librt.so.1 (0xf7c78000)
/lib/ld-linux.so.2 (0xf7f28000)
libm.so.6 => /lib/libm.so.6 (0xf7ba3000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7b9e000)
libc.so.6 => /lib/libc.so.6 (0xf79a1000)
libSDL3_ttf.so.0:
linux-gate.so.1 (0xf7ecc000)
libSDL3.so.0 => ./libSDL3.so.0 (0xf7abe000)
libm.so.6 => /lib/libm.so.6 (0xf79d0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf799a000)
libc.so.6 => /lib/libc.so.6 (0xf779d000)
libdl.so.2 => /lib/libdl.so.2 (0xf7798000)
librt.so.1 => /lib/librt.so.1 (0xf7793000)
/lib/ld-linux.so.2 (0xf7ece000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf778e000)
steamclient.so:
libSDL3.so.0 => ./libSDL3.so.0 (0xf54ca000)
steamui.so:
libSDL3.so.0 => ./libSDL3.so.0 (0xf60f6000)
@lostgoat It's worth mentioning that on the Steam Deck in desktop mode, I had to set the variable to have the UI scaling of the Steam for Linux app work. It wasn't auto-detecting the scaling KDE is set to. After I manually exported the value to match the system scaling it was fine.
@lostgoat Testing flatpak version on Fedora 41: it works without any special env vars! Nice, thanks!
But then I get #9565 where the desktop window is now 2x the scale it was before BPM. One issue at a time :)
Steam Beta Branch: Steam Beta Update
Steam Version: 1730253536
Steam Client Build Date: Tue, Oct 29 10:27 PM UTC -04:00
Steam Web Build Date: Tue, Oct 29 10:01 PM UTC -04:00
Steam API Version: SteamClient021
@perroboc thanks for confirming. We've been working with DE devs to improve scaling detection in SDL, and the recent steam client update pulled in those changes.
Launch options
SDL_VIDEODRIVER=x11`x2 2024-07SDL_Gx1 2024-07SDL_Ix1 2024-07SDL_INIT_VIDEOx1 2024-07
Upstream links
- ValveSoftware/steam-for-linux/issues/5460x10 2023-12
- ValveSoftware/steam-for-linux/issues/9209x1 2023-11
Your system information
Steam client does not respond to scaling settings so it doesn't ready for 4K era
