Improving Xwayland window resizing

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.