Core Analysis¶

Project Positioning: niri is a native Wayland compositor implemented from scratch (in Rust). This gives full control over coordinates, rendering and input while leveraging the wlr protocol compatibility for common features.

Technical Features¶

• Architectural Control: A native implementation avoids compromises imposed by a host Shell’s global coordinate space, enabling consistent monitor isolation, overflow control, and workspace semantics.
• Rust Safety & Tooling: Memory safety reduces system-level crash risks; Rust’s ecosystem facilitates randomized property testing, profiling, and input-latency measurements, improving long-term stability.
• Modular Protocol Compatibility: Using wlroots/wlr makes it easier to support layer-shell, screencopy, gamma-control, etc., while retaining compositor-level control.

Usage Recommendations¶

1. During evaluation, focus on hardware/driver compatibility (notably NVIDIA) and run the provided performance/latency tests.
2. Use the project’s test and configuration examples as a baseline before migrating daily workflows.

Important Notice: Native implementation brings greater control but also greater configuration responsibility (you must provide status bars/panels and integrate extensions yourself).

Summary: Native Wayland + Rust provides stronger semantics (monitor isolation, no forced rearrangement), improved memory safety, and measurable performance characteristics—an appropriate choice for a dependable, long-term compositor design.

Core Analysis¶

Core Issue: Whether to prefer niri depends on your priorities: multi-monitor predictability, pixel-perfect mixed-DPI support, and visual customization (animations/shaders).

Scenarios to Prefer niri¶

• You’re an advanced Wayland user focused on keyboard/tiling workflows across multiple displays and mixed DPI.
• You require windows to remain stable when new windows open, monitor isolation, and workspace migration semantics on disconnect/reconnect (e.g., content creators, multi-screen dev setups).
• You want compositor-level control for gradient borders, custom shaders and fine-grained animations.

Limitations & Alternatives¶

• Not a full DE: You must configure panels/status bars (e.g., waybar) and notifications; GNOME/KDE are better if you want OOTB completeness.
• Touch support: Touchscreen gestures are incomplete—avoid for touch-first devices.
• X11 compatibility: Relies on xwayland-satellite; extreme X11 features or legacy apps may be problematic—consider staying with X11 (i3) or other stable Wayland compatibility layers.
• Alternatives:
• GNOME + PaperWM: Easier to use but limited by GNOME’s global coordinate space—may leak windows across displays.
• i3 / i3-like Wayland variants: Mature and scriptable, better for pure keyboard control without focus on shaders/animations.

Important Notice: Test key workflows (multi-monitor migration, screencast/privacy, X11 apps) in a non-production environment before committing.

Summary: Choose niri if you need predictable multi-monitor scrollable tiling, pixel-perfect UI and compositor-level privacy/recording. For out-of-the-box DE completeness, touch-first usage, or stringent X11 compatibility needs, GNOME/KDE or established tiling WMs may be preferable.

Core Analysis¶

Project Positioning: niri integrates screencasting and casting into the compositor layer and leverages xdg-desktop-portal-gnome for permission handling, while allowing compositor-level blocking of sensitive windows and dynamic cast-target switching.

Technical Analysis¶

• How it works:
• niri uses Wayland’s screencopy protocols and delegates permission gating and sessions to xdg-desktop-portal-gnome.
• The compositor can tag windows as blocked so that when the portal requests a stream, niri provides filtered frames or replacement content.
• Dynamic cast target enables switching sources (monitor/window) or masking rules at runtime.
• Dependencies & limits:
• Functionality depends on correct installation and configuration of the portal service.
• Misconfigured permissions or missing portal components can cause capture failures or ineffective masking.

Practical Recommendations (configuration steps)¶

1. Install and enable xdg-desktop-portal-gnome and ensure the portal daemon is running in your session.
2. Use niri’s screenshot/recording UI to test capture and masking behavior in a local scenario before real use.
3. In multi-user or sandboxed environments (e.g., Flatpak), validate portal permission policies to avoid capture interruptions.

Important Notice: Do not capture sensitive content until you have confirmed masking is effective—perform local tests and keep rollback configs ready.

Summary: niri supports compositor-level screencast privacy, but reliability depends on proper xdg-desktop-portal-gnome configuration and permission management—verify masking behavior before trusting it in sensitive situations.

Core Analysis¶

Project Positioning: niri integrates X11 support via xwayland-satellite (since niri 25.08) and reports that NVIDIA “seems to work fine”, but compatibility depends on driver and Xwayland backend choices.

Technical Analysis¶

• X11 support: xwayland-satellite improves interoperability but edge cases can still occur—window scaling/position issues, focus problems, hardware acceleration or GL context differences.
• NVIDIA drivers: Proprietary drivers involve EGL/GBM/DRM backend choices. Combinations like GBM vs EGLStreams may affect performance and compatibility.

Diagnosis & Fix Steps¶

1. Collect logs: Inspect journalctl -b, niri and Xwayland logs for EGL/GBM/NVIDIA errors and note timestamps.
2. Reproduce: Use the project’s performance/latency scripts or run minimal X11 apps to reproduce the issue.
3. Adjust backends/drivers: Try different Xwayland backend parameters or update the NVIDIA driver; consult distro guidance for Wayland setups (GLVND, GBM settings).
4. Snapshot & rollback: Save known-good configurations to enable quick rollback.
5. Report with context: Provide logs and reproduction steps to niri maintainers if you need help.

Important Notice: Test driver changes in a secondary account or backup environment to avoid session failures on production systems.

Summary: niri supports X11 and NVIDIA paths, but stability depends on the exact driver and backend. Systematic diagnosis (logs + minimal repro) and config snapshots are essential for resolving compatibility issues.