HiDPI Scaling
For users using high resolution displays, primarily on Wayland, there are a few headaches to deal with. Primarily, there is often the tradeoff of applications appearing too small on scaled displays, or appearing crisp only on the scaled displays as the window manager downscales on the unscaled displays.
One of the most frustrating cases is on KDE Plasma Wayland, whereby having some fractional scaled (i.e. 150%) and some unscaled displays (100%), the default option in KDE is for legacy (X11) applications to "Apply scaling themselves". This means X11 applications which can scale, such as native Linux GTK3+/Qt5+ applications, or modern Electron applications such as VSCodium, will look crisp and normal on all displays, just like Wayland applications. However, applications which do not apply scaling themselves, such as GTK2 applications, or most notably the Steam Client, will look fine on the scaled display, but will be downscaled and may be difficult to navigate if they are text-heavy applications, as the text is hard to read.
There are several workarounds possible to deal with these various problems, which will be documented here. If this section becomes outdated, or if there are missing tweaks, document them!
(NOTE: The default value is STEAM_FORCE_DESKTOPUI_SCALING=1)
By default, with a scaled display on Wayland, the Steam Client will not scale up to match the scale factor. Therefore it will look pretty small. Depending on your setup, the text may still be legible, but it is often not the ideal way to interact with the Steam Client.
To fix this, you can launch the Steam Client with the environment variable STEAM_FORCE_DESKTOPUI_SCALING=<scale_factor>. If you're using 150% scaling for example, you can use a scale factor of STEAM_FORCE_DESKTOPUI_SCALING=1.5. Of course, it does not have to match, so feel free to set any scale factor you like. This option quite handily will also apply to the Steam Overlay, though it will not apply to the FPS monitor which is likely taking the game resolution. Therefore, you may want to use an alternative FPS monitoring application, such as DXVK HUD, GalliumHUD (on open-source drivers) or MangoHUD.
It's worth noting that text in the Steam Client, and any other application that has a similar workaround, may look slightly blurry or poorly aliased when on unscaled displays. This is a result of how these applications manage rendering, and is an annoyance that currently has no fix.
There is no option to configure this from SteamTinkerLaunch, but it is a useful tip nonetheless.
(NOTE: The default value is 96)
At the moment, Wine does not have a Wayland driver, and still runs through X11. Likely by design, Wine does not scale up to match fractional scale factors. However, Wine prefixes do have an option to set the rendering DPI, essentially a figure that sets the size of the text and thus scaling up the window content with it. This option is per-prefix meaning you will have to re-apply this to each new prefix created.
Just like with the Steam Client, this option also makes text look somewhat poor on non-scaled displays (see Winecfg screenshot). Once again, there is no known workaround. Playing around with the DPI values is therefore a good idea.
Before doing this, it should be noted that some applications take this DPI value, and attempt to apply their own scaling. For example, when ModOrganizer 2 detects a DPI of 150, it will apply its own scaling factor, making the window larger. In cases like this, you'll have to play around with the DPI scaling value and find the one that suits you best.
Please note that this option only applies to GUI applications, such as game launchers. It does NOT apply to games! This option is useful for making things like Bethesda game launchers appear more readable on scaled displays, but will not make your windowed games any larger! Currently games running under Wine will virtually always use the absolute size of the monitor, so a 720p window will not used any scaled pixels to display itself and will instead render at a true 720p on 4k, without sclaing. There are often per-game workarounds or environment variables to fix this which are discussed later on this wiki page.
This option can be configured from Winecfg, under the "Graphics" tab, and in the "Screen Resolution" section. You can access Winecfg for a game prefix in SteamTinkerLaunch from the One-Time Run menu. Below is a screenshot of my Winecfg setup, where I have chosen a DPI value of 150, as this is what looks preferable to me and my displays including my 150% scaled display. Play around with the values and find one that suits you.
Like with the vast majority of options in Winecfg, the DPI scaling factor is written out to the prefix's registry. It is written out to HKEY_CURRENT_USER\\Control Panel\\Desktop\\LogPixels, stored as hexadecimal. To update this value without the use of Winecfg, you can manually edit the registry. Be careful with which Proton/Wine version you use, as you could update the prefix if you use a version that does not match the last used version in the prefix!
WINEPREFIX="/path/to/prefix" "/path/to/wine/binary" ""
There is a PR up at the moment to implement an option to apply DPI scaling globally to prefixes of games launched with SteamTinkerLaunch by default, or a per-game only/override option (#915). This has not been merged yet and is still under heavy testing. Once merged, this wiki will be updated.
Various toolkits and applications offer the ability to set a scale factor to make them larger. As a reminder, you can set global or per-game environment variables with SteamTinkerLaunch using a configuration file.
These options should be used if applications are not scaling or scaling improperly for you, test your programs first and see how they work before trying these. Scale factors are typically fractional integers, i.e. 150% scaling would be represented as 1.5.
Most of the time, GTK3/GTK4 applications will scale automatically and will look fine on Wayland and XWayland.
For GTK applications, you can set the GDK_DPI_SCALE and/or GDK_SCALE factor values to make GTK applications appear larger. These should go before application launch, for example GDK_SCALE=2 GDK_DPI_SCALE=1.5 <program>.
Note that this will not always work, for example Wine/Wine applications and the Steam Client ignore this. Likewise, it will only work for GTK (or "GNOME") applications. It may work in some cases for native Linux Electron apps.
Qt applications support automatic scaling since Qt 5.6, and should therefore look fine under XWayland.
If a Qt application is not scaling for you, you can force automatic display scaling on for Qt5+ applications with the QT_AUTO_SCREEN_SCALE_FACTOR=1 variable. Note that applications can and sometimes do enforce this at an application-level, meaning it can be difficult to disable.
Otherwise, if you want to force a specific scale factor for a Qt application, you can do so with QT_SCALE_FACTOR=<val>. If automatic scaling is enabled, it will scale up by the value passed from the automatic scale factor found. In other words, if you're running on a 150% scaled display and Qt detects this and scales up, and then you pass QT_SCALE_FACTOR=1.5, then you will end up with a window that is essentially 3x scaled.
This may have mixed results for applications running under Wine, such as ModOrganizer 2, where it may be more difficult to pass environment variables.
Generally, native Linux Electron applications can apply scaling automatically and will look normal under XWayland. Modern Native Linux Electron applications are also using Wayland by default now, as the underlying Chromium engine is starting to move towards Wayland by default. However, this does not apply to applications running under Wine! Some popular examples of Electron games which will not scale properly are Cookie Clicker and Vortex Mod Manager.
To force a scale factor for Electron applications, you can pass --force-device-scale-factor=<val> to your executable before launching it under Wine. For example, with Cookie Clicker under Wine, I use --force-device-scale-factor=1.5 on my scaled display.
If you want to force a native Wayland GTK application to use XWayland instead, you can do so with the GDK_BACKEND=x11 environment variable.
If you want to force a Qt5/Qt6 application to run under XWayland instead of using Wayland, you can do so with QT_QPA_PLATFORM=xcb. Note that this may not work with Flatpaks which use --socket=fallback-x11 (see flathub/net.davidotek.pupgui2#24 for some background).
You can pass the --ozone-platform=x11 flag to modern native Linux Electron applications to force them to use X11. Some older Electron applications may not support this option, but they would be using X11 by default anyway.