Improving Xwayland window resizing

Original Article ↗ Hacker News Discussion ↗

Efforts to improve Xwayland window resizing on modern Linux desktops have reignited broader debate over Wayland’s design trade-offs compared to X11. Commenters weigh smoother rendering and stronger security isolation against real-world regressions such as broken input methods, accessibility gaps, flicker, and missing features like global hotkeys or pointer warping that power users and specialized apps rely on. Many see Wayland as necessary for future-proofing and sandboxing, but argue its ecosystem is still fragmented and slower to match X11’s mature capabilities across hardware, toolkits, and platforms like the BSDs.

Mouse tracking, privacy, and trusted apps

  • Debate around legacy behavior like xeyes:
    • One side values global pointer visibility for customization, automation, and “desktop as a personal machine.”
    • Others argue no random GUI app should see global mouse position/keyboard by default; they see this as a privacy leak and attack surface.
  • Some say such capabilities should be gated by explicit permissions; others see that as “hobbling useful tools” and prefer trusting their installed software set.

Security models: X11 vs Wayland

  • X11 is criticized as fundamentally unsandboxable (any client can keylog or read other windows), making “secure by default” impossible without nested servers.
  • Counterpoint: such attacks are said to be rare in practice; most users rely on vetted distro packages and don’t see real-world harm.
  • Wayland is framed as part of a broader defense-in-depth stack (with Flatpak, etc.), enabling per-app permissions for input, screen capture, and more.
  • Critics argue that without widespread, easy sandboxing, Wayland’s stricter model doesn’t materially help average users and reduces “computing freedom.”

Usability gaps: input, accessibility, and configuration

  • Multilingual and complex input (Greek while-held layout, CJK via Pinyin) is reported as flaky or painful on Wayland compared to X11; environment-variable IM module setup is still fragile.
  • Compose key and .XCompose behavior is inconsistent across toolkits and compositors; some claim it “can’t be done” on Wayland, others say it works but is app/lib dependent.
  • Accessibility, especially screen readers for visually impaired users, is described as badly lagging on Wayland, with fears that dropping X11 will lock out disabled users.
  • Some compare Wayland’s security model to mobile OSes; critics worry Linux will inherit their limitations and “non-standard” apps will be harder to build.

Graphics, jank, and synchronization

  • Many appreciate the article’s Xwayland resize improvement and dislike visible flicker/blank regions during resize; some suspect the demo video’s capture pipeline causes extra jitter.
  • Discussion of Windows/macOS compositors, hardware vs software cursors, and flip-model vsync highlights that smooth resizing is a hard, latency-sensitive problem.
  • Wayland’s mission to eliminate tearing is praised, but several users report more practical “jank” on Wayland (flicker, artifacts, especially with Nvidia) than with X11.
  • Explicit sync is debated: some say Wayland accidentally relied on implicit DRM sync; others insist implicit sync was a conscious design choice now being revisited.

Window management, placement, and decorations

  • Some argue compositors should own resizing and decorations; client-side decorations are seen as messy but entrenched (browsers, large apps demand custom chrome).
  • Wayland’s strict separation means apps can’t freely know screen layout or restore positions; a proposed protocol aims for constrained, relative placement.
  • Critics think per-app window placement state is wasteful and inconsistent; they want the compositor/DE to centrally remember and manage it.

Screen sharing, portals, and platform coverage

  • Wayland’s screen capture goes through xdg-desktop-portal (often via D-Bus), with working setups reported (e.g., Sway plus xdg-desktop-portal-wlr), but also complaints of brittle, hard-to-debug failures.
  • Some say claims of “no screenshots/screencasts” are outdated; others report real breakage (e.g., Webex, screensharing on FreeBSD/Sway).
  • Wayland on BSDs is described as available but uneven; multiple wlroots-based compositors run, but feature parity and ease-of-use lag Linux.

Adoption, philosophy, and future direction

  • Pro-Wayland voices emphasize security, modern features (HDR, precise touchpad gestures, fractional scaling), and note that major distros now default to it.
  • X11 defenders stress its maturity, predictable behavior, and that many “Wayland problems” never affected them on X11.
  • There’s a recurring tension between “secure by default with permissions and sandboxes” versus “simple, powerful, trust-based desktops,” with no consensus on the right balance.