From 291507664278f0df273c31f58b9318ff44b28a18 Mon Sep 17 00:00:00 2001 From: Mariano Abad Date: Sun, 9 Aug 2026 07:04:54 -0300 Subject: [PATCH] fix(linux): bound the xrandr call in the wayland primary-display lookup (#15802) `try_xrandr_primary` runs a bare `Command::new("xrandr").output()`. Its two siblings in the same file, `try_kscreen_primary` and the gdbus one, both go through `run_with_timeout(.., COMMAND_TIMEOUT)`, and the comment above that helper says why: these commands are known to hang. xrandr is the one left bare. It matters because of where it runs. `get_primary_monitor` is called from `get_displays` with the process-wide `DISPLAYS` guard held, and on a Wayland host the caller can be the service, which has no DISPLAY and no session bus. An X client that blocks there blocks every consumer of the display list behind the same lock. No behaviour change when xrandr answers: same command, same parsing, one second of patience. --- libs/scrap/src/wayland/display.rs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libs/scrap/src/wayland/display.rs b/libs/scrap/src/wayland/display.rs index bed90fd76..e3c5ebede 100644 --- a/libs/scrap/src/wayland/display.rs +++ b/libs/scrap/src/wayland/display.rs @@ -76,7 +76,9 @@ fn run_with_timeout( // 2. The distro may not have xrandr installed by default. // 3. xrandr may not report "primary" in its output. eg. openSUSE Leap 15.6 KDE Plasma. fn try_xrandr_primary() -> Option { - let output = Command::new("xrandr").output().ok()?; + // Bounded like its two siblings below: this runs inside the held `DISPLAYS` guard, and from a + // service with no DISPLAY and no session bus, where an X client can block indefinitely. + let output = run_with_timeout("xrandr", &[], COMMAND_TIMEOUT, "xrandr")?; if !output.status.success() { return None; }