You connect a 4K laptop or a 1440p external monitor to your Fedora workstation. The desktop boots, but the interface is microscopic. Terminal text requires squinting. Window controls overlap. You need fractional scaling to make the desktop readable without wasting half your screen real estate on empty padding.
What the compositor is actually doing
Display scaling used to be a binary choice. You picked 100 percent or 200 percent. Modern panels have pixel densities that fall between those markers. A 125 percent or 150 percent scale factor bridges the gap. The compositor renders the entire desktop at a higher resolution, then shrinks it down to match your physical panel. Wayland handles this at the protocol level. X11 relies on Xft and application-level hints, which is why fractional scaling feels inconsistent on Xorg sessions.
The scale-monitor-framebuffer feature tells the GNOME compositor to allocate a larger virtual framebuffer and apply the scaling factor before sending frames to the GPU. When you enable it, the compositor multiplies the logical pixel grid by your chosen factor. A 1920x1080 logical desktop at 150 percent becomes a 2880x1620 rendering target. The GPU draws to that larger buffer, then the display server downsamples it to your physical panel. Text remains crisp because the font rasterizer works at the higher resolution. Vector UI elements scale cleanly. Raster images and legacy X11 windows may show slight blur because they were not designed for non-integer scaling.
Wayland clients receive the scaled coordinates directly from the compositor. X11 clients run inside Xwayland and rely on the X server to translate coordinates. That translation layer introduces rounding errors and occasional misalignment. Run your session on native Wayland whenever possible. Fractional scaling is a compositor feature, not a kernel feature. The kernel only cares about the final framebuffer dimensions sent to the display controller.
Enable fractional scaling in your session
Here is how to activate the framebuffer scaling backend and set your preferred factor from the terminal.
# Enable the fractional scaling backend in GNOME Mutter
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"
# Apply a 150 percent scaling factor to the desktop interface
gsettings set org.gnome.desktop.interface scaling-factor 1.5
# Force the shell to reload the display configuration without a full reboot
gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval "global.reexec_self()"
Restart your session or reboot for changes to take effect. The reexec_self() call works in most cases, but a clean logout and login guarantees the compositor reinitializes its rendering pipeline. If you are using GNOME 43 or newer, the Settings application exposes fractional scaling directly under Displays. The terminal commands remain useful for automation, headless configuration, or recovery when the GUI is unresponsive.
Configure the login screen separately
The GDM display manager runs in its own isolated session. It does not inherit your user gsettings values. The login screen will stay at 100 percent unless you configure it explicitly.
Here is how to apply fractional scaling to the GDM login screen.
# /etc/gdm/custom.conf
# Uncomment and set the Wayland scaling factor for the login screen
[daemon]
WaylandEnable=true
# Add this line to force GDM to use 150 percent scaling
# Note: GDM reads this from the environment before starting the session
# Create or edit the GDM environment override file
sudo tee /etc/profile.d/gdm-scaling.sh > /dev/null << 'EOF'
# Export the scaling factor for GDM and all display managers
export GDK_SCALE=1.5
export GDK_DPI_SCALE=1.0
EOF
# Set executable permissions so the shell sources it on login
sudo chmod +x /etc/profile.d/gdm-scaling.sh
Reboot before you debug. Half the time the symptom is gone after a clean display manager restart. The GDK_SCALE variable tells GTK applications to multiply their logical coordinates by the specified factor. The GDK_DPI_SCALE variable remains at 1.0 because the compositor already handles the physical DPI translation. Changing both simultaneously causes double scaling and breaks window placement.
Verify the scaling factor
Here is how to confirm that the compositor is actually using your fractional scaling configuration.
# Check the active scaling factor for the current user session
gsettings get org.gnome.desktop.interface scaling-factor
# Query the Wayland compositor for the active monitor configuration
loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Display
# Inspect the journal for compositor initialization messages
journalctl -xeu gdm | grep -i "scale\|fractional\|framebuffer"
Run journalctl -xe first. Read the actual error before guessing. The x flag adds explanatory context to each log line. The e flag jumps to the end of the journal. Most sysadmins type journalctl -xeu <unit> muscle-memory style when troubleshooting display managers. If the compositor reports scale-monitor-framebuffer in its feature list, the backend is active. If you see fallback messages about X11 or integer scaling, your session is not running native Wayland.
Common pitfalls and what the error looks like
Fractional scaling introduces predictable tradeoffs. Integrated graphics controllers struggle with the extra framebuffer allocation. A 150 percent scale on a 4K panel forces the GPU to render at 5760x3240. That extra pixel count increases memory bandwidth usage and can drop frame rates in video playback or window animations. If you notice stuttering, lower the factor to 125 percent or switch to integer scaling.
Mixed DPI setups cause alignment issues. A laptop screen at 200 percent paired with an external monitor at 125 percent forces the compositor to draw separate framebuffers for each output. Window dragging across the boundary may snap or jitter. The compositor cannot blend different scaling factors in a single surface. Keep per-monitor scaling consistent when possible.
Legacy X11 applications ignore the Wayland scaling hint. They render at 100 percent and appear tiny inside the scaled desktop. You can force individual applications to scale by wrapping them in env GDK_SCALE=1.5 <command>. Do not apply this globally to X11 apps. The coordinate translation breaks drag-and-drop and breaks clipboard sharing.
If you see [FAILED] Failed to start gdm.service after editing display configuration, your environment variables probably contain a syntax error or an unsupported value. GDM refuses to start when GDK_SCALE is set to a non-numeric string. Check /var/log/secure and journalctl -u gdm for the exact failure reason. Restore the original configuration from a TTY before rebooting.
Choose the right scaling strategy
Use native Wayland fractional scaling when you want crisp text and smooth window animations on modern panels. Use integer scaling at 200 percent when you are running legacy X11 applications that require exact pixel alignment. Use per-monitor scaling when your laptop and external display have drastically different pixel densities. Stick to 100 percent when you are running compute-heavy workloads on integrated graphics and need every megabyte of VRAM. Trust the compositor. Manual Xft DPI overrides drift, Wayland scaling stays consistent.