diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/TODO.md | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/docs/TODO.md b/docs/TODO.md index 1de3cee..7a11584 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -266,6 +266,16 @@ Not fixed generically this session - the immediate, concrete mitigation the user Second-order finding from a peer session verifying the above: `grim`'s own multi-output capture is *itself* affected by the same physical/logical confusion, independent of anything srdwm's compositor code does - capturing two 1920x1080-logical outputs (one at scale 1.0, one at ~0.843) produced a single stitched image sized `3840x1281`, not `3840x2160`(both at scale) or `3840x1080` cleanly, meaning the capture tool's own per-output stitching mixes physical and logical sizing across outputs of different scale. `srd clients`/`srd monitors` report physical throughout (this compositor's own established convention); a screenshot taken across a sub-1.0-scaled output can't be trusted to line up with those numbers pixel-for-pixel without correcting for whatever `grim` itself did - a testing-infrastructure gap on top of the client-rendering one, not fixable from srdwm's side either. One more argument for clamping the floor at 1.0, alongside the client-compatibility one above. +## Real bug, root-caused and fixed: a window dragged or resized onto a different-scale monitor rendered "very messed up" for the whole gesture, only correcting itself on release (2026-08-25) + +Reported live: moving a window onto the other monitor looks very messed up. This machine's own two real monitors have genuinely different scales (`srd monitors`: `eDP-1` at `1.0`, `HDMI-A-1` at `~0.843`, the same auto-scaled-below-1.0 monitor the 2026-08-21 entries above already have a long history with) - the exact condition needed to expose this. + +Root cause in `WindowManager::update_drag`/`update_resize` (`crates/core/src/manager/dragresize.rs`): `w.monitor` used to only get corrected once, at `end_drag` (`update_resize` never corrected it at all, not even at the end) - but `state/geometry.rs::sync_geometry`, called on every single motion tick while a drag or resize is in progress, reads that exact field to pick which monitor's `scale` converts the client's real physical size into the logical points `xdg_toplevel::configure` sends it. Dragging (or resizing) a window from one monitor onto the other kept every mid-gesture configure computed against the *origin* monitor's stale scale for the gesture's entire remaining duration - the client resizing itself to a logical size that doesn't match the physical footprint the border/decoration were actually drawing around it on the *new* monitor, self-correcting only the instant the button came up (which is when `end_drag`'s own existing fixup finally ran). + +Fixed at the source, same "close the gap where the field actually goes stale" approach as this session's earlier resize-lag fix: both `update_drag` and `update_resize` now re-derive `w.monitor` from which monitor the window's live geometry actually overlaps, every motion tick, the same `Rect::overlaps`-based lookup `end_drag` already used once at the very end. `end_drag`'s own fixup is left in place as a final-word safety net (a drag that starts and ends between two motion ticks would otherwise skip the correction entirely), now normally just reconfirming what `update_drag` already set. + +Does not fully close the family of scale-crossing issues this shares a root cause with - see the 2026-08-21 entries just above: a client that doesn't speak `wp-fractional-scale-v1` will still show a content/frame mismatch once *settled* on the sub-1.0-scaled monitor, independent of this fix, which only closes the *stale-during-the-gesture* half of the problem. Two new tests (`dragging_across_a_monitor_boundary_updates_monitor_live_not_just_at_end`, `resizing_across_a_monitor_boundary_updates_monitor_live`); full workspace test suite (195 core / 124 wayland) and clippy clean; installed, pending a live restart to confirm. + ## Real bug, root-caused, not yet fixed: `com.canonical.AppMenu.Registrar` is owned by AGS, not srdwm, despite srdwm's own code deliberately trying to claim it (2026-08-21) Flagged by a peer session (`dotfiles-04`): `busctl --user list` shows the classic Qt/`appmenu-qt5` global-menu registrar name owned by AGS's own `gjs` process, not srdwm - confirmed live (`OwnerUID` traced to the AGS pid). `AppmenuRegistrarState::new()` (`crates/platform/src/appmenu_registrar.rs`) is genuinely constructed at startup (`xwayland.rs`'s `XWaylandEvent::Ready` handler, alongside `EwmhState::connect`) and its own D-Bus name request sets `replace_existing_names(true)` - and srdwm's log has no warning from the `Err` branch that would fire if the connection/name request failed outright, meaning the `zbus` call chain reports success from srdwm's own side despite not actually owning the name afterward. |