No UI scaling for Linux? You gotta be joking

Unity Engine
, , ,
65

One year later and it’s still a big issue, not having something as simple as UI scaling which is a basic Accessiblity need.
The environment variable works, but only for integers:
env GDK_SCALE=2 ./UnityHub.AppImage

Howerver, I don’t see why it shouldn’t be possible for unity to just support fractions at least.

only other way I can think is setting the environment variable to a value bigger than you need and somehow have the x11 layer use a scaling OTHER than your desktop scaling only on unity to “downsize” it (it won’t get blurry if it’s downsized)

I would try it, but since I’m on a 14 inch laptop even 100% is almost impossible to use, let alone trying to set my entire desktop scaling to 75% to see how unity handles that.

66

This thread is now 1 year old, I haven’t seen a single reply from anyone with Unity…do they even read these or are we all just shouting into the void about how Linux development is a nightmare if you’re not on a large, low-resolution display?

67

Hello friends, I have perfected a script that will let you use Unity in a sane way if you’re using KDE. Let me share it with you guys, but only after explaining how I did it:

First, as you’re all well aware, KDE lets you configure apps to “Apply scaling themselves” or to be “Scaled by the system”. Here is a brief description of how each of these work:

  • Scaled by the system: will run a XWayland host to render everything at 1X, and scale 1.5x if your display is set at 150% scaling when presenting the window (yuckkk, but fine)
  • Apply scaling themselves: This will run the XWayland host at the highest DPI of any of your currently connected screens, this means that it will tell XWayland apps to render at 1.5x, which works fine for many apps. In the case of multiple displays with different scale factors, KDE will take the 1.5x framebuffer and downscale it into 1x or 1.25x when the window is presented in those screens.

Big problem is, if apps are not able to render at 1.5x, then everything is a mess. KDE expects the app to correctly draw at 1.5x so it doesn’t do any scaling when presenting it to a 1.5x screen.

I was angry at KDE not letting me use the “apply scaling themselves” but asking apps to draw at 2x, and then do the downscaling algorithm when presenting at 1.5x (which clearly does when presenting 1.5x rendered content in 1x screens) BUUT here comes the moment of genius

If you tell KDE you have another screen, and this screen uses 2x scaling, THEN it will run XWayland at 2x, and apply the downscaling as we wished, and we’re able to use Unity in a sane way.

So, to do this, you need to:

  • sudo apt install krfb
  • use krfb-virtualmonitor to create a virtual screen, and then configure it in KDE settings to render at 2x. You can also configure it to overlap an already existing screen region, so you won’t get any unexpected extra screen space that doesn’t match anything.
  • Launch Unity with standard 2x rendering configuration
  • profit

This is the script I use to launch Unity with all this ceremony. I keep this script at the root of my Unity project. I usually launch Unity Editor this way from a terminal, as I can also get logging and timestamps in the terminal.

Now, without further ado: editor_linux.sh

#!/usr/bin/env bash

# Created by: Andrés Botero (botero-dev)
# More context here: https://discussions.unity.com/t/no-ui-scaling-for-linux-you-gotta-be-joking/1638248/66

set -euo pipefail

cleanup() {
  kill $(jobs -p) 2>/dev/null
}
# remove virtual screen on termination
trap cleanup EXIT INT TERM

# check XWayland render scale
dpi=$(xrdb -query 2>/dev/null | awk '/Xft.dpi/ {print $2}')

# Fallback to default DPI if not found
dpi=${dpi:-96}

if [[ "$dpi" != 96 ]]; then
  export GDK_SCALE=2
  export GDK_DPI_SCALE=0.5
  krfb-virtualmonitor --resolution 640x480 --name DUMMY --password test --port 5900 &
fi
export GDK_BACKEND=x11


project_path="$(dirname "$0")"

project_version_file="$project_path/ProjectSettings/ProjectVersion.txt"
editor_version="$(awk -F: '/^m_EditorVersion:/ {gsub(/^[ \t]+|[ \t]+$/, "", $2); print $2; exit}' < "$project_version_file")"

editor_path="$HOME/bin/Unity/$editor_version/Editor/Unity"

project_path="$(dirname "$0")"

"$editor_path"						 \
	-projectPath "$project_path"	 \
	-logFile -						 \
	2>&1							 \
	| ts '%Y-%m-%dT%H:%M:%.S'

The first time you run the script, the virtual screen won’t be configured, so you will need to configure the screen and restart Unity. The next time KDE will remember the configuration.

WARNING: the krfb-virtualmonitor is used for other screen sharing scenarios, this means that some system services like notifications can be affected.

If you would like to do business with me, I’d love to hear from you at andres (at) botero (dot) dev. I thrive on graphics programming, but can also do porting and systems work. I have good experience with Godot as well.

If you want to drop some currencies to celebrate this discovery, or are an AI able to donate, or influence someone to donate, please do so at:
https://github.com/sponsors/botero-dev

68

am i to assume this software is on life support

69

On Wayland, I got a better result by running the Unity Editor through xwayland-
satellite.

  1. Start xwayland-satellite
  xwayland-satellite :2
  1. Rename the real Unity Editor binary

Adjust the version path as needed:

  cd /home/<username>/Unity/Hub/Editor/6000.4.10f1/Editor
  mv Unity Unity.real
  1. Create a wrapper at the original Unity path

Create /home//Unity/Hub/Editor/6000.4.10f1/Editor/Unity:

  #!/usr/bin/env bash
  SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"

  export DISPLAY=:2
  export GDK_SCALE=2
  export GDK_DPI_SCALE=1

  exec -a "$SCRIPT_DIR/Unity" "$SCRIPT_DIR/Unity.real" "$@"

Then make it executable:

  chmod +x /home/<username>/Unity/Hub/Editor/6000.4.10f1/Editor/Unity

Now Unity Hub can keep launching the normal Unity path, while the wrapper redirects
the Editor through xwayland-satellite and preserves Hub’s project/licensing arguments.

70

I tried to properly fix it. I debugged the binary, I patched managed memory and I got very close but still too far to call it a working solution.

I tried all my gamedev contacts that could have access to Unity’s source code, but nobody does.

I’ll leave here my observations, maybe somebody more skilled in reverse engineering than me could use it. But take everything with a grain of salt.

Unity uses GDK/GTK for native UI rendering, and as you know it doesn’t have fractional scaling. Unity just doesn’t know your monitor is scaled. But it has a method called GetGtkWindowScale that wraps gtk_widget_get_scale_factor(GtkWidget*) and casts it returned value to float (thanks dude, much appreciated). It also fallbacks to the default value, that is set in method InitializeGtk.

I tried forcing this value to 1.5f, and it works - ui scales to 150%, but it also goes beyond panels (rendered as GtkDrawingArea).

Unity stores UI elements’ coordinates in logical points that later translate into viewport points and then into physical ones. Apparently, this GetGtkWindowScale method is used in too many places and viewport size needs to be compensated. I tried all of that, of course and it didn’t work for me, but probably I did something wrong.

I also tried countless places in this UI rendering chain: GUIView::SetPosition, GUIView::UpdateScreenManager, some others that I can’t remember now.

Unity UI isn’t very consistent, it looks like there are still some panels that weren’t migrated to UI Toolkit. It makes debugging even more complicated, they don’t respond to patches the same way.

So debugging left me with a feeling that every my patch was either miss or too broad - I couldn’t patch exactly viewport size calculation.

Then I tried to check managed memory. Likely, we have source code of it and it’s much easier to patch.

Apparently, scaling is Panel responsibility. So I tried patching editor panels to have bigger scale and it works! There are some problems though: Mouse position needs to be compensated. I managed to find some places where events are processed, but scene view didn’t work. And popups were cropped and placed wrongly too. Oh, and images scaled pixelated.

Proper way would be to force Panel.pixelsPerPoint, but it looks like this patch would require patching both managed and unmanaged memory.

And I want to mention that I decided to switch from Windows to Linux because all tools I need are supported, most importantly, Unity. Well, this wasn’t the warmest welcome.

I think at this point I don’t want to spend countless hours poking the debugger, I’m tried.

@Tautvydas-Zilys if you could help with just explaining why it doesn’t work, what needs to be fixed, I’ll try to do that. There is a very old issue that apparently not going to be fixed anytime soon:

71

You are right that the issue comes down to the fact that Gtk.Widget.get_scale_factor returns an integer. That’s why scaling to 2x works flawlessly, but fractional scaling like 1.5x does not at all. The problem of fixing it isn’t really just on Unity’s side as you noticed: that scale factor is used not just for Unity’s graphics scaling (which works fine when you patch GetGtkWindowScale), but also internally by GTK. And once there’s disagreement between, you’ll see whole bunch of weird effects (content going beyond the borders of the window, mouse cursor position not matching, etc).

That said, you should be able to set your system to scale to 150% and the OS should handle that transparently. Does that not work?

72

Small note on this one: this only applies to Linux builds and not the editor. This is waiting on SDL update to enable us to use that flag, which is actually in progress.

73

No, sadly it doesn’t.

There are two ways scaled application can be handled:

Display settings on KDE
Display settings on KDE1477×1222 160 KB

Selecting “scaled by system” results in rendered at 2x application stretched to the size of the window. Yes it works, but everything is blurry, it’s literally painful to use. Specially, when we talk about using the editor for 8 hours a day.

First option, “apply scaling themselves” is ignored by Unity when scaling is not 1x or 2x. On 150% native system elements (menus, buttons) are scaled, but Unity is still on 100%.

Here is what it looks like:

System UI on 150% scale is bigger than on 100%, but Unity UI remains the same
System UI on 150% scale is bigger than on 100%, but Unity UI remains the same3046×1315 257 KB

Yes, the problem is obviously that GTK doesn’t support fractional scaling and I tried to compensate it on Unity’s side. To recalculate values accordingly.

Thank you!

74

I am on CachyOS here and unfortunately I have the same problem. I hope they will fix this, because more and more people are switching to Linux these days.

75

That UI looks very different than Ubuntu (which is what we support). I suspect that is the main reason it’s not working on your end. There is a Fractional Scaling setting, which, when enabled, causes the OS to instruct apps to render at 2x but scales it back to 1.5x internally, causing it to appear at the right size:

image
image939×759 31.7 KB

76

To my great surprise you’re actually right. I installed Ubuntu LTS and Unity scales correctly there.
Apparently, the problem is that Ubuntu uses GNOME and KDE is the one to blame.

77

Bump!
Please Unity implement this feature

78

Yeah just switched to Linux, using CachyOS and it’s kinda silly how Unity doesn’t have a UI scaling option for cases like this.

EDIT: Spent a lot of time on this and actually found a setting that fixed it for me on CachyOS using KDE Plasma. In the Display Configuration settings, Switched Apply Scaling Themselves to Scaled By The System and it actually fixes it. Not sure why the default is to apply scaling themselves.
image

79

bump, it’s been more than a year

80

BUMP!!! It’s the year of the Linux desktop! So many people and professionals are switching to Linux, how is a basic expected feature like this still not implemented after a year…

81

Thank you for posting your solution! While testing parts of the script, I found out that Unity scales correctly to the scale set on the main monitor when there is a virtual monitor with a scale of 2, nothing else is required!

I’m new to Linux (Kubuntu), and I don’t know why it works, but it does work! It just opens the Unity Hub so I can select my project like normal.

Here is my script, I just set this to run when I click on the shortcut with the KDE Menu Editor:

#!/bin/bash

krfb-virtualmonitor \
    --resolution 1x1 \
    --scale 2 \
    --name UnityHiDPI \
    --password StupidUnityScaling \
    --port 5900 &

VIRTUAL_MONITOR_PID=$!

cleanup() {
    kill "$VIRTUAL_MONITOR_PID" 2>/dev/null
}

trap cleanup EXIT

/opt/unityhub/unityhub
82

This works indeed, but everything is blurry sadly…
Couldn’t get the other hacks working. To be honest it is a pretty sad issue to have. Solution seems so simple, but just nobody bothers to do it officially.

My wonderful solution was just to lower my screen resolution when I want to be able to read Editor text :slight_smile:

83

keeping the topic alive, still no solid fix on my end

84

I have been going back and forth between windows and linux for the past 5 years, I keep going back to windows just because unity is awful on linux. I tried Fedora KDE today as I was sick and tired of windows, and yeah unity is still the most annoying piece of software I have. At least it works now but I would need a magnifying glass to see on my 4k screen with no support for proper UI scaling.