fix(vdisplay): compositor availability follows the live session, not the env
GNOME/Mutter reported "Unavailable" on a host sitting in a live Mutter session — and, on the same request, "Default", because the two columns had different sources. available() asked each backend, and those probes read the process env (XDG_CURRENT_DESKTOP for Mutter, WAYLAND_DISPLAY for KWin's registry handshake, SWAYSOCK for sway) — env a host started outside the session (systemd --user, a TTY, ssh) never inherited. It is only retargeted at the live session on the connect path, so the answer also flipped depending on whether anyone had connected yet. Both columns now come from the same /proc scan detect() already used: the live session's compositor is usable by definition, as is an explicit operator pin, and the per-backend probe stays as the fallback for backends that are not the live session (gamescope, which spawns its own). A live KWin without the zkde_screencast grant now surfaces as available and fails at create with that probe's precise message, which beats "no usable compositor" on a box visibly running KDE. Mutter's env sniff stays deliberately narrow — one var, not three. XDG_CURRENT_DESKTOP is the one apply_session_env owns end to end (written per connect, scrubbed when nothing is live); sniffing DESKTOP_SESSION alongside would resurrect the bug that scrub exists to prevent, where a stale value after a gnome-shell crash routes the next client into a dead session. Non-Linux hosts now report no compositors at all rather than five Linux backends flagged unavailable with no default — on Windows the pf-vdisplay driver is the only backend and vdisplay::open ignores the argument, so the old list read as broken detection instead of "not applicable here". The console says so explicitly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit eb7ba3d6177552f5c3ed6a15439404084869c636)
This commit is contained in:
@@ -105,8 +105,17 @@ impl MutterDisplay {
|
||||
}
|
||||
|
||||
/// Mutter is usable when the host runs inside a GNOME session (its `RecordVirtual` D-Bus API
|
||||
/// drives the *live* compositor). Cheap signal: `XDG_CURRENT_DESKTOP` names GNOME — same basis
|
||||
/// as [`super::detect`], avoiding a blocking D-Bus round-trip on the enumeration path.
|
||||
/// drives the *live* compositor). Cheap env signal, avoiding a blocking D-Bus round-trip on the
|
||||
/// enumeration path.
|
||||
///
|
||||
/// This is the *fallback* answer only: [`crate::available`] treats a running `gnome-shell` (the
|
||||
/// `/proc` scan) as the authority, because this var belongs to the session and a host launched
|
||||
/// outside it — `systemd --user`, a TTY, ssh — never inherited it. Deliberately still just the ONE
|
||||
/// var: `XDG_CURRENT_DESKTOP` is the one [`crate::apply_session_env`] owns end to end (it writes it
|
||||
/// per connect and *scrubs* it when nothing is live), so sniffing `DESKTOP_SESSION` /
|
||||
/// `XDG_SESSION_DESKTOP` alongside would resurrect the bug that scrub exists to prevent — a stale
|
||||
/// `gnome` there after a gnome-shell crash reports Mutter usable and routes the next client into a
|
||||
/// dead session (45 s create timeouts instead of a crisp handshake error).
|
||||
pub fn is_available() -> bool {
|
||||
std::env::var("XDG_CURRENT_DESKTOP")
|
||||
.map(|d| d.to_ascii_uppercase().contains("GNOME"))
|
||||
|
||||
Reference in New Issue
Block a user