Apps blurry or huge with fractional scaling on Omarchy

Omarchy ships assuming a 2x retina panel. On anything else you end up picking a fractional monitor scale, and then some apps look right, some look enormous, and some look soft. Checked on 4.0.4, with the 4.0.0 to 4.0.3 behaviour noted where it differs.

The fix

1. Set the monitor scale. Print the focused monitor’s scale with omarchy hyprland monitor scaling, or see every output with hyprctl monitors -j | jq '.[] | {name, width, height, scale}'. Step through the presets with Super + / (up) and Super + Alt + / (down), or set one directly:

omarchy hyprland monitor scaling 1.6

The presets in 4.0.x are 1, 1.25, 1.6, 2, 3 and 4. Hyprland only accepts scales that divide the mode into whole logical pixels in 1/120 steps, so the command rounds your request up to the nearest clean value. That is why asking for 1.5 on some panels lands you somewhere else.

2. Match GDK_SCALE to it. Open ~/.config/hypr/monitors.lua (Setup > Monitors in the Omarchy menu). The stock file has two variables:

local omarchy_gdk_scale = 2
local omarchy_monitor_scale = "auto"

GTK only honours whole numbers, so set omarchy_gdk_scale to the nearest integer of your monitor scale: 1 for 1 and 1.25, 2 for 1.6 and 2. A fractional value is silently truncated: colutti’s GDK_SCALE,1.75 on 3.0 left Steam rendering at 1x (issue #2058). Save, then quit and relaunch every oversized window. GDK_SCALE is read at launch, not live. On 3.x the same two knobs live in ~/.config/hypr/monitors.conf as env = GDK_SCALE,2 and a monitor=,preferred,auto,auto line.

3. Refresh the launch environment. If apps started from the menu or a keybinding still come up at the old size after a scale change, the systemd user manager is still exporting the old value. Check and fix it:

systemctl --user show-environment | grep GDK_SCALE
dbus-update-activation-environment --systemd GDK_SCALE=1

Geokec reported this on 4.0.2 with Spotify (issue #10555). The environment import runs on Hyprland start only, so a mid-session scale change never reaches it. PR #10570 adds the sync to the scaling command; it was still open when 4.0.4 shipped, so keep the command handy.

4. Leave the text-size knob alone while you debug. omarchy display text size <9-20> moves the shell font, the GTK text-scaling-factor and your terminal point size together. Chromium and Electron multiply that GTK factor into their own device pixel ratio, so anything other than the default 12 changes how Electron apps lay out. Reset it with:

omarchy display text size reset

Above 12 the factor clips fixed-size Electron dialogs, measured by SilentKernel at a device pixel ratio of 2.72 on a 2x monitor at text size 16 (issue #8574). Below 12 the whole Electron surface undershoots the Hyprland window and leaves wallpaper showing, reported by jonnyace at text size 10 (issue #8716). PR #8825 proposes a --no-gtk flag so the bar slider stops touching GTK; both it and PR #8575 were still open at 4.0.4.

5. Per-app flags for the stragglers. 1Password’s main window was fixed in 4.0.3: omarchy-launch-1password now runs 1password --force-device-scale-factor=1, listed in the release notes as “Fix oversized 1Password windows on scaled displays”. That covers the hotkey and menu launch only. The background instance that pops the SSH and CLI prompts is started from ~/.config/autostart/1password.desktop, which 1Password rewrites without the flag, so those prompts still come up unscaled (dmthepm in issue #8716). For other Electron apps with clipped or oversized windows, the same flag goes in ~/.config/<app>-flags.conf, one flag per line, where the package’s launcher reads one. Spotify still runs on XWayland, which is why it ignores per-output scale on mixed-DPI setups (issue #11175). Create ~/.config/spotify-flags.conf:

--ozone-platform=wayland

That is the flag nightdevil00 posted for 3.x in issue #3309. dhh declined to ship it because on his setup Spotify under Wayland laid out too wide, so check the window after switching; the window class also changes from Spotify to spotify, which breaks any rule matching the old name (issue #11175). Omarchy does not ship this file on 4.0.4; it ships chromium-flags.conf only, which its browser installer copies for each Chromium-based browser.

6. Repaint corruption at 1.6. If Electron secondary windows leave stale or duplicated regions at a fractional scale, d-geula found that disabling one Chromium feature clears it (issue #9907):

--disable-features=WaylandFractionalScaleV1

Verify it worked

Run these after relaunching the affected app.

omarchy hyprland monitor scaling            # focused monitor scale
omarchy display text size                   # px, gtk text-scaling-factor, terminal pt
systemctl --user show-environment | grep GDK_SCALE
hyprctl clients -j | jq '.[] | {class, xwayland}'

The text-size command should report 12, 1.0 and 9 pt on a stock system. Anything listed with "xwayland": true will not follow per-output scale, so judge it separately. In a Chromium window, the devtools console reporting window.devicePixelRatio should equal your monitor scale, not the scale times the text factor.

Why it happens

Three scaling layers stack, and they do not agree.

Hyprland gives native Wayland clients a fractional output scale, and they re-render for it. GTK’s GDK_SCALE is an integer multiplier applied at app launch. GNOME’s text-scaling-factor, which the Omarchy text-size knob drives, is a third multiplier that Chromium and Electron fold into their device pixel ratio.

On top of that, default/hypr/envs.lua sets xwayland.force_zero_scaling = true. XWayland clients therefore get 1:1 physical pixels and have to enlarge themselves through toolkit settings. That keeps them sharp instead of compositor-upscaled, but it means an X11 or Java app sees a 1920 wide screen and a GDK_SCALE of 2 at the same time, and asks for windows twice as wide as it needs. v-t-r-gg measured a client advertising a 1530px minimum width where 765 was correct (issue #7021). Going the other way, forcing --force-device-scale-factor=1 on a scaled monitor makes the app render at 1x and the compositor upscale it, so text goes softer. kurtome flagged that trade-off in issue #9904.

If that did not work

The scale presets silently do nothing if you have written explicit per-output hl.monitor lines in monitors.lua. The scaling command persists a single global variable, so the file reload undoes its own live change (issue #9950). Per-monitor scaling and the bar’s Display panel are effectively mutually exclusive on 4.0.x.

Two failures look like scaling but are not. A Chromium profile bubble that opens as a thin clipped sliver is triggered by the window’s logical width, not the scale, and reproduces at integer scale 1 as well (issue #7676). Qt apps that go blurry only after closing and reopening the laptop lid look like an output hotplug bug rather than a configuration problem, and that report has been open since 3.x with no fix (issue #1847).

Mixed-DPI multi-monitor setups have no merged fix as of 4.0.4: issues #7021, #9950 and #11175 all land on the same limit, that GDK_SCALE is one session-wide integer standing in for a per-output fraction. Until that changes, pick the scale that is least wrong for the monitor you use most and give XWayland apps their own flags.

Related

• Monitor layout lost after Quattro
• Multi-monitor layout not saved
• 1Password not opening or wrong scale
• Multi-monitor hardware notes
• Fractional scaling and HiDPI apps when switching
• omarchy-display-text-size
• Omarchy manual chapter: Monitors