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.
While it is possible to modify/create a new Steam Desktop Entry to automatically add this environment variable to your existing Steam entry (if you have one), this can cause Steam to forget your previously selected library folders for some reason, and you'll have to re-add them. It's a real pain, so personally I just run the command from KRunner. Running from the commandline with STEAM_FORCE_DESKTOPUI_SCALING=<val> nohup steam also works.
There is no option to configure this from SteamTinkerLaunch, but it is a useful tip nonetheless.
(NOTE: This only works for native Linux titles, and it will break the Steam Overlay as it does not support Wayland!)
Some newer SDL2 games have a Wayland backend, as SDL2 itself is integrating improved support for Wayland. This allows games to run natively on Wayland, which has benefits such as proper handling of fractional scaling.
To enable this option, you can pass the SDL_VIDEODRIVER=wayland environment variable to your game. There is a SteamTinkerLaunch Game Menu option "SDL Wayland video driver", which will export the variable automatically. You can also configure this from the per-game config file using the SDLUSEWAYLAND variable.
Support and functionality of this backend may vary greatly between games, so it is not a catch-all solution. Likewise, many SDL games may not support this. In the future, this may work well with GameScope's --expose-wayland flag, but currently this seems to cause scaling issues and crashes in tested games.
I have tested this option with Factorio and Dwarf Fortress, where Factorio appears to work flawlessly, and Dwarf Fortress works with minor background image scaling issues.
(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!
The below command will update the DPI scaling in the given prefix to 150.
WINEPREFIX="/path/to/prefix" "/path/to/wine/binary" "reg" "add" "HKEY_CURRENT_USER\\Control Panel\\Desktop" "/v" "LogPixels" "/t" "REG_DWORD" "/d" "150" "/f"
(NOTE: If enabled, these settings are applied on game launch)
There are options on the SteamTinkerLaunch Global Menu and Game Menu to configure the Wine DPI scaling. By default these are both disabled, but can be toggled on and a value can be set.
This option should apply to custom commands and commands executed using One-Time Run, anything that uses the Game Prefix should have this scale factor, unless it has some strange application-specific behaviour.
The Global value can be useful if you want all applications to use a specific scale factor by default. Some applications may not work well with the DPI factor increased, or may need a larger DPI.
Global Scale factor will not apply to every game automatically, but will simply automatically apply to any game launched with SteamTinkerLaunch while this option is on. Therefore, your games that are not launched with SteamTinkerLaunch will be unaffected, but this means all previously launched games will have this DPI scale value unless they are re-launched with the Global Scale having a different value.
It is probably not feasible to track and unset the DPI value for every game, but feel free to open a PR if you want to implement functionality like this.
The Per-Game DPI will override the Global DPI. In cases where the Global Scale may be problematic, such as with ModOrganizer 2, this value can overridden to a different value in the Per-Game options.
When these options is disabled, the DPI value will NOT be reset back to 96. This is because there is no way for SteamTinkerLaunch to know when the option was disabled by the user, or when the value was manually set by the user, and we don't want to overwrite any manual configuration where we can help it. Therefore, you will either need to manually set the DPI for your games back to their default of 96, or you can use SteamTinkerLaunch to set the Global Scale factor.
You can re-configure the DPI value using Winecfg, which can be activated from the One-Time Run menu, or before a game launch with the Winecfg checkbox. You can also automatically re-configure the DPI scaling using the commandline option to run the reg command with Wine. You can get the game prefix with steamtinkerlaunch gc <appid>, and you can check the Wine version used for the game in the game config, which you can find details on the location of on the Paths wiki (generally it is ~/.config/steamtinkerlaunch/gamecfgs/id/<appid>.conf).
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.
SteamTInkerLaunch mostly works fine under Wayland. There are some sizing issues that may come as a result of relying on some X11 sizing, but these issues are relatively inconsistent.
If SteamTinkerLaunch is causing issues for you under Wayland, you can use the Global Menu option "Force XWayland" which will force GDK_BACKEND=x11. This can also be configured with the YADFORCEXWAYLAND variable in the global config file.
For the SteamTinkerLaunch global menu, we enforce GDK_BACKEND=x11 for compatibility and this cannot be changed.
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.