Image quality degrades in fullscreen games (looks like 1080p downscaled to ~480p)

[pwned666]

Description

In fullscreen the in-game image looks noticeably worse, as if downscaled (like 1080p shown at ~480p).
Tested on CS2. On Hyprland at 2048x1080 the quality is excellent; on driftwm at 2048x1080 in CS2 it is
clearly worse, with identical in-game settings on both compositors.

This item is not confirmed end-to-end from the code, so please treat it as a question + symptom report
rather than a definitive root cause. If the output scale is 1.0 the logical size equals the native
2048x1080 and the configure is correct, so the culprit is likely elsewhere (no direct scanout, an extra
blit/scale, or a scale/filtering mismatch during composition).

Environment

• my monitor: 3440x1440
• driftwm version: git-last
• disable_direct_scanout value: false (default)
• GPU / driver: 595.71.05
• Compared against: Hyprland at 2048x1080, identical in-game settings

Steps to reproduce

1. Use the same monitor mode (2048x1080) and identical in-game settings on both compositors.
2. Run CS2 fullscreen on Hyprland — sharp.
3. Run CS2 fullscreen on driftwm — visibly softer / lower quality.

Expected behavior

Fullscreen renders at the native output resolution, matching Hyprland.

Actual behavior

Fullscreen looks downscaled / blurry compared to Hyprland with the same settings.

Questions for the maintainer

1. What exact size is sent in enter_fullscreen_configure for a given output — logical (scaled) vs native
   physical — and is fractional scale applied?
2. Does the fullscreen window actually hit direct scanout, or is it composited / rescaled through GLES?

Code-level findings (verify before relying on these)

• enter_fullscreen sends the client enter_fullscreen_configure(viewport_size), where
  viewport_size = get_viewport_size() — a logical size.
• enter_fullscreen_configure (src/window_ext.rs) sets xdg_toplevel::State::Fullscreen and state.size = Some(size).
• The render path (src/render/mod.rs) uses output.current_scale().fractional_scale() and to_physical_precise_round(scale).
• Direct scanout for fullscreen is gated by disable_direct_scanout / ALLOW_PRIMARY_PLANE_SCANOUT_ANY
  (src/backend/udev.rs). If the fullscreen buffer is not scanned out directly (unlike Hyprland, which can
  scan out the buffer 1:1), an extra blit/scale step may soften it.
• Useful to attach: the Backend config: ... disable_direct_scanout=... log line from udev.rs, a run with
  disable_direct_scanout=false, and the output's current_scale().

[malbiruk]

Thanks for the detailed report. Before looking at the renderer, I'd like to rule out a mode mismatch — the symptom could come from the game being upscaled rather than rendered at native.

CS2 doesn't do a real modeset: it renders at 2048×1080 and Xwayland asks the compositor to scale that up to the panel. So if driftwm is running your 3440×1440 panel at native, the game would be stretched, which can look soft. One thing worth checking: a bare mode = "2048x1080" only picks a mode your monitor advertises (EDID). If your panel doesn't list 2048×1080, driftwm keeps the preferred mode and logs a warning rather than switching. To force a non-advertised mode, the refresh form is needed: mode = "2048x1080@60".

Could you grab:

1. wlr-randr output while CS2 runs — which mode the panel is actually at.
2. Your exact mode string ("2048x1080" vs "2048x1080@60").
3. Whether the driftwm log mentions No mode matching 2048x1080, falling back to preferred.

If the panel turns out to be at 3440×1440, that would explain it. If it's genuinely at 2048×1080 and still soft, that points to a real bug — in which case it'd be useful to compare against niri, which also runs X11 games via xwayland-satellite: blurry there too would suggest the shared XWayland path, sharp would point back at driftwm's compositing.