Why am I getting blurred fonts in Linux apps in ChromeOS?

Question

I have 4k monitor connected and on ChromeOS itself fonts look excellent and sharp:

But all apps running on Linux VM has ugly, blurred fonts:

Is there any way make fonts for Linux apps rendered the same as on main ChromeOS system?

Answer 1

Obviously your VM is not set to the native resolution.

In virtual machines you have to assure the capabilities of your physical display are passed into the VM so the auto-detection of the Linux can do the rest.

If that is not the problem, might be the High-DPI compensation features are active:

You should look at the configuration of the "display settings" within your Linux in the VM. There often are some sort of scaling setting available (availability and appearance depend on your Linux distribution):

• "User interface scale" (set to 100% or "normal")
• Fractional scaling controls

On command-line you can check

xrandr --query

for more information.

Some sample output of xrandr --query:
(the "current" value is of interest.)

Screen 0: minimum 320 x 200, current 1920 x 2160, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+0+1080 (normal left inverted right x axis y axis) 346mm x 194mm
   3840x2160     60.00*+  59.98    59.97  
   3200x1800     59.96    59.94  
   2880x1620     59.96    59.97  
   2560x1600     59.99    59.97  
   2560x1440     59.99    59.99    59.96    59.95  
   2048x1536     60.00  
   1920x1440     60.00  
   1856x1392     60.01  
   [...]

UPDATE: Container

As you write, you are not using a VM but CromeOS' container feature to run Linux apps the settings within the VM are not relevant for your question.

X-apps and Wayland-apps are served by ChromOS' own nested Wayland compositor called "Sommelier".

To take control you start the Linux-app using Sommelier at the commandline of the ChromeOS Terminal, providing environment and parameters:

sommelier -X --scale=0.75 --dpi="120" inkscape

--scale=0.75 will scale the display. A value larger than 1 will tend to blur font and object within the container. This parameter has only influence within the window of the container

SOMMELIER_SCALE=0.75 is the environment variable that represents the same as the parameter --scale=0.75. The parameter should override the environment setting.

GDK_SCALE=2 influences the Gnome desktop. This is the Hi-DPI compensation for all apps in the Gnome Desktop, so also Sommelier/Wayland/X11 as a "onion shell" that wraps the results of Sommelier.

Many Linux apps read the DPI (Dots Per Inch) and compensate their internal sizing to provide a native, smooth and sharp experience for the Hi-DPI problem. Having proper DPI settings for each connected display provides the chance that the app will present its content in almost the same size on all connected displays.

--dpi="" or not mentioning it will provide the exact DPI-settings of the display known by ChromeOS to the Linux app run in Sommelier.

--dpi=120 will override the DPI value provided by ChromeOS.

--dpi=75,96,120,160,200,240 will provide a "bucket" of valid DPI-values to Sommelier. A real DPI value of 172 will be passed as 160 to the Linux app. This is sometimes necessary as some Linux apps only accept some discrete values as valid DPI settings. These you have to find out and write in the "bucket", when you experience unexpected sizing within distinct Linux apps.

---

To "remove" the blurring in your Linux app, you should first start with --scale=1. And only use this single scaling factor.

As the not setting GDK_SCALE the global setting of this variable will be active, the blur provided by this parameter should be the same at all ChromeOS apps and Sommelier apps.

If the blurring disappeared you should judge the sizing of the objects within the Linux app compared to the sizing of the other ChromeOS apps.

1. If in all apps the objects are to small/large, then the GDK_Scale is the right parameter to tune. But as this is a scaling of pixels any value larger than native GDK_Scale=1.0 will result in more or less visible blurring. Helpful are straight factors like 1.5 or 2.
   Note that just changing GDK_Scale in a terminal will not have influence to the other CromeOS apps. This you have to change at the global settings.

2. If only the Linux app's sizing is uncomfortable, then you have to weight the (dis-)advantages of --scale=... and --dpi=....

   • --scale=<value> (or SOMMELIER_SCALE=<value>) larger than native 1.0 will start blurring. Here also straight factors like 1.5 or 2 help to make the blurring less visible.
   • --dpi=<value> will fix the used DPI of the app and changing the display at a multi monitor setup might produce unwanted jumps in the displayed sizing. But it offers the chance to prohibit blurring and get the desired sizing.

---

Please provide some feedback of your test results and decisions.

Answer 2

I also run into this with my external 4K monitor but there's a trick I've learned to work around the problem.

If I close the lid of my Chromebook and use only the LG HDR 4K (3840x2160) by itself when first launching the Linux container (and app) then the result is blurry text. If I launch the app with the Chromebook open and then close the lid then the text is crisp.

It seems to me that there are settings "at boot time" for the Linux container relating to DPI that do not get auto-configured correctly unless the built-in laptop screen is on as well (or only, in some cases).

At one time I had a script for launching VS Code that forced the correct DPI but I can't seem to dig it up now and the sommelier stuff above is not working for me when I run something like this:

sommelier -X --scale=1.0 --dpi=120 code

Result:

sommelier_scope_timer: init wayland channel: 0.000484 seconds
sommelier_scope_timer: drm device: 0.008052 seconds
sommelier_scope_timer: connect display: 0.000026 seconds
sommelier_scope_timer: client create: 0.000030 seconds
sommelier_scope_timer: display implementation: 0.000001 seconds
sommelier_scope_timer: spawn xwayland: 0.000295 seconds
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Error:            Key <CAPS> added to map for multiple modifiers
>                   Using Mod3, ignoring Lock.
Errors from xkbcomp are not fatal to the X server
Got error or hangup (mask 5) on X connection, exiting
eweplay9@penguin:~$ sommelier -X --scale=1.0 --dpi=120 edge