From a4710d792a1b16698fc30b9e97e6c08c82129d6d Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Wed, 29 Oct 2025 22:24:00 +0200 Subject: Fix set_monitor_split never actually reaching srd monitors Live-tested right after shipping it and caught immediately: srd dispatch set output split returned ok, but srd monitors kept reporting the whole, unsplit output. WindowManager::monitors is a passive cache, only refreshed when a backend re-queries and calls set_monitors again - the IPC handler mutated the split map directly but never triggered that requery, unlike set_output_position's own drain site, which already pushes a "just go recompute" event after applying. Makes it a proper queued cross-boundary request instead, the same shape as every other backend-owned effect on this socket: WindowManager:: request_monitor_split/drain_monitor_split_requests, dispatch queues instead of mutating, the udev backend's poll drains it, applies via set_monitor_split, and pushes the same recompute event. srd.monitor. split's Lua config-time path is untouched - it runs before the very first startup query, so it never had this problem. --- crates/platform/src/ipc/dispatch.rs | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'crates/platform/src/ipc/dispatch.rs') diff --git a/crates/platform/src/ipc/dispatch.rs b/crates/platform/src/ipc/dispatch.rs index 665cb59..918b7e0 100644 --- a/crates/platform/src/ipc/dispatch.rs +++ b/crates/platform/src/ipc/dispatch.rs @@ -322,17 +322,17 @@ pub(crate) fn handle_request(line: &[u8], wm: &std::rc::Rc}` - the live CLI/IPC path // for `srd.monitor.split(name, parts, direction)` (`crates/config/ // src/engine/general.rs`'s own `fn_monitor_split`), which until now - // only ever ran once at config load. `WindowManager:: - // set_monitor_split` just mutates `monitor_splits`, and every - // backend's own `monitors()` already reads that map fresh on every - // single call (see the udev platform's own `monitors()`) - so, - // unlike `set_output_position`/`set_output_enabled` above, this - // needs no queue-and-drain at all: the very next `monitors()` query - // already reflects it. `parts` <= 1 clears an existing split, same - // as the Lua function. Same "resolve id to a name first" fallback - // `set_output_enabled` above already uses, since a caller working - // from a numeric id shouldn't have to look the name up itself - // first just to turn around and split it. + // only ever ran once at config load. Queued via `request_monitor_ + // split`, same cross-boundary "core has no way to trigger its own + // requery" reasoning as `set_output_position` above - see + // `WindowManager::monitor_split_requests`'s own doc comment for the + // real, live-reproduced staleness bug that came from calling + // `set_monitor_split` directly here on a first attempt. `parts` <= + // 1 clears an existing split, same as the Lua function. Same + // "resolve id to a name first" fallback `set_output_enabled` above + // already uses, since a caller working from a numeric id shouldn't + // have to look the name up itself first just to turn around and + // split it. "set_monitor_split" => { let name = match req.get("name").and_then(|v| v.as_str()) { Some(name) => Some(name.to_string()), @@ -343,7 +343,7 @@ pub(crate) fn handle_request(line: &[u8], wm: &std::rc::Rc,"path":, -- cgit v1.2.3