High resolution displays became normal faster than the software stack adapted. Integer scaling has worked well for years. Fractional scaling is where the complaints are, and understanding why involves knowing which applications are drawing at which resolution.

Integer versus fractional

Integer scaling, 200 percent, maps every logical pixel to exactly four physical ones. Nothing is interpolated and the result is perfectly sharp. This has worked on Linux for a long time.

Fractional scaling, 125 or 150 percent, does not divide evenly. Either the application renders at that exact scale, which requires it to support the idea, or something renders at a different scale and resamples, which is where blur comes from.

How Wayland handles it

Under Wayland the compositor tells each application its scale factor and the application renders accordingly. A native Wayland application at 150 percent draws at 150 percent and looks sharp.

The problem is XWayland. X11 applications cannot be told about fractional scale factors, so they draw at 1x or 2x and the compositor scales the result. That resampling is the blur.

So on a fractionally scaled display you get a mix: native Wayland applications sharp, XWayland applications soft. Which explains why some windows look fine and others do not, on the same screen, at the same time.

Recent compositors implement a fractional scale protocol that improves this, and applications still need to support it.

Setting the scale

GNOME:

# Enable fractional scaling if not already on
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Then choose the scale in Settings, Displays.

KDE Plasma: System Settings, Display and Monitor, with a per-display scale slider. KDE has supported per-monitor fractional scaling for longer than most.

wlroots compositors such as Sway and Hyprland:

output DP-1 scale 1.5

X11, where it is worse:

xrandr --output DP-1 --scale 0.8x0.8

X11 has one global scale for the session. Mixed-DPI setups fundamentally do not work well, and this is a design limitation rather than an unimplemented feature.

Forcing applications onto Wayland

The most common fix for a blurry application is making it render natively.

Electron applications, which are the usual offenders:

myapp --enable-features=UseOzonePlatform --ozone-platform=wayland

Make it permanent by editing the .desktop file, or globally:

echo "--enable-features=UseOzonePlatform" >> ~/.config/electron-flags.conf
echo "--ozone-platform=wayland" >> ~/.config/electron-flags.conf

Qt applications:

QT_QPA_PLATFORM=wayland myapp

Firefox uses Wayland by default now. If yours does not:

MOZ_ENABLE_WAYLAND=1 firefox

Check what an application is using:

xlsclients     # anything listed is on XWayland

Toolkit specifics

GTK handles Wayland scaling well. For X11 sessions:

export GDK_SCALE=2
export GDK_DPI_SCALE=0.5     # compensate font size after GDK_SCALE

Qt on X11:

export QT_AUTO_SCREEN_SCALE_FACTOR=1
export QT_SCALE_FACTOR=1.5

Java applications, a perennial problem:

export _JAVA_OPTIONS='-Dsun.java2d.uiScale=2'

Cursor size, which frequently goes wrong across mixed DPI:

export XCURSOR_SIZE=48

Choosing a scale

Physical size and viewing distance matter more than resolution.

• 27 inch 4K: 150 percent is usually comfortable; 200 percent makes everything large
• 14 inch 4K laptop: 200 percent is often exactly right
• 32 inch 4K: many people run it at 100 percent
• 1440p at 27 inch: usually no scaling at all

If 200 percent is close to comfortable, use it, because integer scaling is sharp everywhere and avoids the entire fractional problem. Slightly larger and perfectly sharp often beats correctly sized and soft.

Mixed DPI

A HiDPI laptop with a standard external monitor is the hard case.

Wayland handles it properly with per-output scale factors and windows re-rendering as they move between screens. X11 cannot, and the usual workarounds involve a global scale that is wrong for one display.

If you routinely work across mixed-DPI monitors, that alone is a reason to use a Wayland session.

Frequently Asked Questions

Why do some applications look blurry at fractional scaling?

Because they render at a lower resolution and get scaled up by the compositor. This affects X11 applications running through XWayland, which cannot be told about fractional scale factors, so they draw at 1x or 2x and are then resampled.

What is the difference between integer and fractional scaling?

Integer scaling multiplies by a whole number, so every pixel maps to an exact block and the result is perfectly sharp. Fractional scaling uses values like 1.25 or 1.5, which do not divide evenly, so something has to resample unless the application renders at that scale natively.

Does mixing displays with different DPI work?

On Wayland, yes, and per-monitor scale factors work properly. On X11 it does not work well, because X11 has one global scale factor for the session, which is a fundamental limitation rather than a missing feature.

How do I fix a blurry Electron application?

Make it run natively on Wayland rather than through XWayland, usually with the ozone platform flags. Many Electron applications still default to XWayland even when a Wayland session is available.

Should I use a 200 percent scale on a 4K display?

On a 27 inch 4K panel, 150 percent is usually more comfortable and 200 percent makes everything large. On a 14 inch 4K laptop, 200 percent is often exactly right. It depends on physical size and viewing distance, not resolution alone.

Why is my cursor huge or tiny on one monitor?

Cursor scaling is handled separately and some toolkits get it wrong across mixed-DPI setups. Setting XCURSOR_SIZE explicitly usually resolves it, and on Wayland the compositor scales the cursor per output where the client supports it.