fix: pointer constraints, xwayland positioning, and physics tick

[sevenluckz]

This PR addresses Xwayland coordinate sync issues and hardens the compositor's core pointer constraint logic.

1. Xwayland default cursor

Fetches the default xcursor buffer and sets it via wlr_xwayland_set_cursor to prevent the legacy X11 fallback cursor.

2. Xwayland Positioning/Physics Tick

Translates world coordinates to screen coordinates during view_set_size to restore hit-testing on non-primary desktops.

Xwayland coordinates are also continuously synced (view_sync_position) during physics glides and drags to prevent detached popups and dropdowns. To support desktop switching, this synchronization caches the computed sx/sy screen coordinates, naturally treating coordinate translation failures as un-cached.

3. Pointer Constraints & Crash Fixes

Hardens both LOCKED and CONFINED pointer constraints:

• Locked constraints: Replaced an early return with a locked boolean check to keep the cursor visually frozen and suppress motion events while still allowing focus/hit-testing to process.
• Confined constraints: Replaced manual boundary-dropping with wlr_region_confine to strictly clamp the pointer.
• CSD Geometry Insets: Constraint regions now subtract XDG surface geometry offsets to align with true surface coordinates.
• Window tracking: Actively warps the locked cursor alongside the window during physics glides to maintain its relative position (gated to LOCKED constraints).
• Off-screen focus & Cursor freeze: If a confined/locked window drops out of bounds or leaves the active display, the pointer is permitted to move and naturally update focus, breaking the lock via constraints_follow_focus(server, NULL) without forcing the seat's pointer focus.
• Double-Free Crash fix: Fixed a SIGSEGV in server_seat.c caused by a double wl_list_remove. The constraint listener is now unhooked before sending the deactivated signal to prevent memory corruption.

[iluaii]

Thanks — I went through all three commits and built the branch against wlroots 0.20. It compiles clean and merges cleanly on current main. Two of the three I'd take as they are; one needs a change before I merge.

1. xwayland: set fallback cursor — correct, and the comment you deleted was simply wrong.

fwm does draw the pointer itself, but it takes the image from the client (handle_request_set_cursor, src/server_seat.c:85). An X11 client that never sets a cursor inherits the root window's, which defaults to the black X, and Xwayland forwards exactly that to us. So the root cursor does have to be set. Good catch.

2. xwayland: fix pointer coordinates on non-primary desktops — correct, and it makes the code match what the tree already claimed.

Both the comment in view_set_size ("send screen coords") and src/server_shell.c:133 ("X11 windows are always configured at screen coords") said this was already happening, while view->x went out in world coordinates. Override-redirect placement is built on that assumption, so the bug was real and this is the right fix. Your error handling is right too: server_world_to_screen (src/server_output.c:483) leaves the outputs untouched when it fails, and you pre-seed sx/sy with the world values, so a desktop that is off every monitor falls back to the old behaviour rather than to garbage.

One gap this leaves, which is not a regression and does not need to be in this PR — view_sync_position runs on events (server_camera_settled, desktop change, drag, expo), not per frame. A window flying under physics, or any window while the camera slides, still reports stale coordinates to X. It used to be wrong always; now it is wrong only in motion.

3. pointer: correctly handle locked pointer constraints — right diagnosis, but it lets in something I'd rather keep out.

The part I agree with entirely: the early return meant constraints_follow_focus never ran while the pointer was locked, so the active constraint was never re-evaluated. That is a genuine hole.

But the same change now also runs focus-follows-pointer on every motion event under a lock. The cursor is frozen, yes — the windows are not. fwm's windows drift and get thrown around on their own, and when one lands under the frozen cursor, server_focus_view (src/server.c:135) raises it to the top and takes the keyboard away from the game in the middle of mouse-look. The old early return ruled that out. It won't fire spuriously (server_focus_view returns early on an unchanged view), but the focus can change, and during mouse-look it must not.

Could you keep the constraint bookkeeping and leave focus alone:

if (view && !locked) server_focus_view(server, view);

Same class of thing, lower stakes, up to you: drag_icon_update_position, expo_handle_motion, launcher_handle_motion and server_drag_motion now also run while locked. They see unchanged coordinates, so in practice they do nothing — it just no longer reads as "the pointer is frozen".

Ping me when you've marked it ready and I'll merge. Nice digging — you found two places where the comments and the code had drifted apart.

[sevenluckz]

Hey, this is all I have for the moment!

I've hopefully solved the focus issue you mentioned, and I also added logic to track the cursor in relation to the window when it's locked (and instantly drop the lock if the window goes off-screen). I also moved the CONFINED constraint handling over to wlr_region_confine to prevent the cursor from escaping its boundaries during fast mouse flicks.

Finally, I added more position updates for Xwayland while its windows are moving to fix an issue I noticed where detached UI elements (like dropdown menus) were not updating their positions dynamically.

[iluaii]

Thanks for this — I built the branch against wlroots 0.20 and it compiles clean, all 7 ctest targets pass. Replacing the manual boundary drop with wlr_region_confine and dropping the early return for LOCKED are both clearly right, and the fallback cursor commit is self-contained and good to go.

Three things I'd like fixed before merging, all in the constraint/physics commits:

1. The view_sync_position cache defeats the coordinate fix it ships with (src/view.c:168)

The early-out keys on view->x/y, i.e. world coordinates. But server_camera_settled() (src/server_tick.c:869) re-syncs every view after the camera moves precisely because the screen coordinates changed while view->x/y did not — server_world_to_screen() subtracts o->camera_x. So after a desktop switch, an X11 window that didn't move never gets a new configure, and it keeps the root coordinates from the old camera. That's the exact case point 4 of the description sets out to fix.

Cache the computed sx/sy instead of view->x/y (and treat a server_world_to_screen() failure as "not cached", since the fallback there is the raw world position).

2. The cursor warp during glides isn't gated on LOCKED (src/server_tick.c:1157)

The condition is just server->active_constraint, so a CONFINED constraint drags the user's cursor along with a window that flew off — the pointer was never handed over in that case. Please check constraint->type == WLR_POINTER_CONSTRAINT_V1_LOCKED.

Also worth a comment: dx/dy are world deltas passed to wlr_cursor_move(), which takes layout coordinates. They agree only while the camera is standing still, which is not true during a slide.

3. Breaking the lock off-screen does more than break the lock (src/server_tick.c:1170)

Besides deactivating the constraint it force-sets the default xcursor and calls wlr_seat_pointer_clear_focus(), even though the pointer may legitimately be sitting over some other window at that moment. constraints_follow_focus(server, NULL) alone already deactivates the constraint, and the next motion event restores focus and the correct cursor image on its own.

Minor, not a blocker and pre-existing: the region offset is computed from cv->x/cv->y, the window origin, while the constraint region is in surface coordinates — those diverge for CSD geometry insets.

One process note: the PR title reads as a cursor fix, but only d7fc7c8 is that; the other seven commits reach into the physics tick and Xwayland positioning. If you'd rather land something quickly, I'm happy to take the fallback-cursor commit on its own and review the constraint work separately.

[iluaii]

Marking this as changes-requested so the status is visible in the UI — my earlier feedback went out as plain comments, so GitHub never flagged the PR and it may well have been lost in your inbox. Nothing new here, this is just the checklist from #8 (comment):

1. src/view.c:168 — cache the computed sx/sy rather than view->x/y, and treat a server_world_to_screen() failure as "not cached". As written the early-out skips the reconfigure after a camera move, which is the case the coordinate fix exists for.
2. src/server_tick.c:1157 — gate the cursor warp on constraint->type == WLR_POINTER_CONSTRAINT_V1_LOCKED; a CONFINED constraint shouldn't drag the pointer along.
3. src/server_tick.c:1170 — on breaking the lock, constraints_follow_focus(server, NULL) is enough; drop the forced default xcursor and the wlr_seat_pointer_clear_focus().

No rush on my end, and no need to rebase or reshape anything. The standing offer also holds: if you'd rather land something now, I'll take d7fc7c8 (fallback cursor) on its own and we can keep the constraint work in this PR.

[sevenluckz]

I've pushed updates to address your feedback:

1. view_sync_position cache: Updated to cache the computed sx/sy screen coordinates instead of the view->x/y world coordinates, properly treating a server_world_to_screen() failure as not-cached.
2. Cursor warp during glides: Gated the cursor warp on constraint->type == WLR_POINTER_CONSTRAINT_V1_LOCKED. Also added a comment noting that dx/dy are world deltas which only agree with layout coordinates while the camera is stationary.
3. Off-screen constraint breaking: Removed the forced wlr_seat_pointer_clear_focus() and default cursor setting. It now relies purely on constraints_follow_focus(server, NULL) to deactivate the constraint.

Minor (CSD Geometry Insets): Updated handle_cursor_motion to subtract the XDG surface geometry offset, so constraint regions use true surface coordinates.

I've also included fixes for related edge cases found during testing:

• Cursor Freeze: Fixed an issue where the cursor freezes if a confined window drops out of bounds (e.g., due to gravity). The pointer is now allowed to move outside the region, triggering a normal focus update that breaks the constraint.
• Double-Free Crash: Fixed a SIGSEGV in server_seat.c caused by a double wl_list_remove. The listener is now removed before wlr_pointer_constraint_v1_send_deactivated to prevent memory corruption if the constraint is destroyed synchronously.

[iluaii]

Thanks — all three checklist items are addressed, and I rebuilt the branch against wlroots 0.20.2: it merges cleanly onto current main, compiles without warnings, and all 10 ctest targets pass.

Confirming what's now settled:

1. src/view.c:156 — the cache keys on the computed sx/sy and a server_world_to_screen() failure invalidates it, so a camera move does reach X now. server_world_to_screen tolerates NULL out-params (src/server_output.c:483), so the NULL, NULL probe in the tick is fine too.
2. src/server_tick.c:1164 — gated on LOCKED, with the world-vs-layout caveat written down.
3. src/server_tick.c:1175 — down to constraints_follow_focus(server, NULL) alone.

And the CSD inset is handled via xdg_toplevel->base->current.geometry, which is what I meant.

38d8cc8 is a genuine find and the fix is the right one — the header says it outright: "Deactivate the constraint. May destroy the constraint." With lifetime == ONESHOT, wlr_pointer_constraint_v1_send_deactivated() destroys the object synchronously, handle_constraint_destroy removes the listener, and constraint_set_active then removes it a second time. Unhooking before the signal is correct.

Two things left, then I'll merge.

1. Off-screen X11 windows now get a configure every tick (src/view.c:156, src/server_tick.c:1162)

view_sync_position() runs unconditionally for every unpinned body in the physics tick, which includes every window sitting on a desktop no monitor is showing. For those server_world_to_screen() fails, so the cache is stamped with -999999, the early-out can never hit, and wlr_xwayland_surface_configure() goes out at 60 Hz per window — carrying raw world coordinates, which is the value the early-out was there to suppress in the first place. Clients that relayout on ConfigureNotify (Chrome, anything AWT) will do it 60 times a second while parked on another desktop.

Cheap fix: keep a bool last_sync_onscreen alongside the coordinates, cache whatever was actually sent in both cases, and compare all of it. That also retires the -999999 sentinel.

2. The comment under locked says the opposite of what the code does (src/server_pointer.c:145)

/* Mouse-look: the cursor does not move at all, but we still need
 * to send motion events with constant coordinates. */

The code deliberately skips wlr_seat_pointer_notify_enter/motion while locked, which is right — the client is getting relative motion from the relative-pointer protocol, and absolute motion under a lock is exactly what we're suppressing. The reason to fall through is hit-testing and constraints_follow_focus. Could you reword it to say that?

Neither of these needs a reshape, and no rush.

Two non-blockers for the record, no action needed here:

• If wlr_region_confine() ever returns false the pointer is freed, but should it still be over the same surface, constraints_follow_focus re-arms the same constraint while every subsequent motion also starts outside the region — so confinement stays broken until focus actually leaves. In practice the pointer is inside the region at activation, so this only bites after a set_region while the pointer is elsewhere. I'll open an issue rather than grow this PR.
• af1900d duplicates a8ec5a6, which landed on main after you branched. Identical change, merges clean, ends up a no-op — nothing to do, I'll just drop it from the squash message.
• Seven of the added lines carry trailing whitespace.

[iluaii]

Heads up: main moved under this branch and it now conflicts, in the one file this PR lives in.

1727912 gives the pointer an implicit grab — a button press pins the pointer to the surface it landed on until the button comes back up, because every motion re-asking the scene what was underneath meant a client dragging a splitter or a panel divider lost the pointer the moment the hand ran past the thing it was pushing. It adds ~90 lines above handle_cursor_motion and rewrites the delivery tail of that function, which is exactly where your constraint work sits. Git reports the conflict in src/server_pointer.c alone; the rest of the branch still applies.

It is worth resolving by hand rather than by taking a side, because the two changes meet on the same question. handle_cursor_motion now ends:

if (server_drag_motion(server, lx, ly, &now)) return;
if (pointer_grab_deliver(server, lx, ly, event->time_msec)) return;
pointer_update_focus(server, lx, ly, event->time_msec);

Your locked flag suppresses wlr_seat_pointer_notify_enter/motion and falls through for the sake of hit-testing and constraints_follow_focus. pointer_grab_deliver is a second reason to not re-ask what is under the cursor, and it returns true when it has handled the motion. Under a lock they want the same thing, so the merge should end up with one path, not two that each partly suppress delivery — the grab is the more general statement of "the pointer is spoken for".

Also note pointer_update_focus is now where focus-follows-pointer lives, so the if (view && !locked) guard we agreed on earlier has moved into that function.

No rush, and nothing about the review changes — the two items from my last comment still stand (the 60 Hz configure storm for off-screen X11 windows, and the comment at what is now a different line number in server_pointer.c). I would just rather you rebase before doing them than do them twice.

[iluaii]

I've taken 38d8cc8 onto main as d808223, with your authorship on the commit. Before asking anything more of you, I owe you a straight account of what happened to the rest of this branch, because a good part of it is my doing rather than yours.

The constraint listener crash was real, and it was still live on main until today.

Your diagnosis was exactly right: wlr_pointer_constraint_v1_send_deactivated() destroys a ONESHOT constraint synchronously, handle_constraint_destroy removes the listener, and the wl_list_remove that followed removed it a second time. I rewrote constraint_set_active on August 4th and 6th without carrying your fix across, so the same ordering was sitting there again. That one is on me.

I did have to resolve the conflict rather than replay the commit, and the resolution is not the two-line swap you wrote — the function grew a cursor hint in the meantime, and unhooking the listener first turns the double-remove into a use-after-free instead of fixing it. With the listener gone, send_deactivated() still frees the constraint, and pointer_apply_constraint_hint(server, old) on the next line then reads it. The order that satisfies both is:

wl_list_remove(&server->constraint_destroy.link);  /* unhook before the signal */
server->active_constraint = NULL;
pointer_apply_constraint_hint(server, old);        /* read while old is alive */
wlr_pointer_constraint_v1_send_deactivated(old);   /* old may die here */

Your fix, plus the hint moved ahead of the signal for the same reason yours moved the unlink. Builds clean against wlroots 0.20, 12/12 ctest.

Four of your commits are on main already, in my words rather than yours.

While this PR was waiting on a rebase, I landed my own versions of work you had already written and I had already reviewed and agreed with:

here	on main
d7fc7c8 fallback cursor	bd5805b (Aug 4)
18ffe47 screen coords in view_set_size	2b242c9 (Aug 4)
420d28d / 2d9d574 locked constraints and focus	2a8ad80 (Aug 4), 4e36000 (Aug 6)
af1900d stale camera across drags	a8ec5a6

I should have cherry-picked those from you on the day I reviewed them, or told you I was going to write them myself. Instead I asked you to hand-resolve a conflict against the very commits that had displaced your own, on the same day I pushed them. If that is why the branch went quiet, it was a fair reading and I don't blame you for it.

For what it's worth on attribution: your commits here are authored as 7luckz@noreply.feather.city, which isn't a verified address on your GitHub account, so the API reports them as unlinked and they won't show up on your profile or contribution graph regardless of how they land. Worth adding to your account's emails if you'd like the credit to stick — here or anywhere else.

What is genuinely still missing from main, and still yours:

1. 072df92 — wlr_region_confine for CONFINED constraints. main has no wlr_region_confine anywhere; the manual boundary drop is still what's there, flicks still escape it.
2. 48c69a2 / cfde0f7 — the sx/sy cache and continuous Xwayland position sync during physics. This is the gap I flagged in my first review and never closed: coordinates are still stale for anything in motion.

Both are things I'd still like, and neither is invalidated by what landed. Whatever suits you:

• Rebase and keep going. The conflict is confined to src/server_pointer.c, and I'd resolve it toward pointer_grab_deliver as the single "the pointer is spoken for" path. Happy to do the rebase myself and hand you back a clean branch to work on.
• Hand it off. Say the word and I'll finish those two from your commits, with your authorship preserved the way d808223 is.
• Close it. Also completely fine, and no hard feelings if this has stopped being worth your evening.

No deadline attached to any of that. Thanks for the crash — it was a genuinely sharp find, and it would have kept biting.

[sevenluckz]

Hey, thanks for the review. Sorry for taking a while to get back to this.
No worries about the displaced commits, and I appreciate the detailed explanation of what happened!

I've decided to take the option to rebase and keep going. I've rebased the branch onto the latest main to align with the new pointer_grab_deliver implicit grab architecture and pushed the remaining missing bits, along with a quick fix for a new issue I noticed:

1. Pointer Constraints: I've ported the LOCKED constraint logic directly into the new pointer_grab_deliver function, ensuring that pointer locks are correctly maintained during interactive compositor events without cursor drift.
2. Xwayland Configure Storm: Addressed the 60Hz configure storm for off-screen Xwayland windows by caching last_sync_onscreen inside FwmView, ensuring we only send updates when the window actually crosses the screen boundary.
3. Interactive Window Moves: I noticed that the new implicit grab logic on main caused the compositor to permanently swallow left clicks after a window drag. During a compositor-driven drag (FWM_ACTION_MOVE), handle_cursor_button swallows the release event, leaving wlroots' button_count stuck at 1 and permanently locking pointer_grab_deliver. I've added a fix that correctly forwards the release event to balance the initial press, restoring normal mouse behavior.

Regarding the git config issue with the commit author, that was indeed a fault with my config and thanks for pointing it out. It should be fixed for my previous and future commits.

Let me know if everything looks good now!

[iluaii]

Thanks for coming back to this, and for taking the rebase — it landed cleanly. The branch sits on adb5f38, builds against wlroots 0.20 with no new warnings (the two that do appear are in config_binds.c and server_config.c, neither of which you touch), and all 16 ctest targets pass. The attribution is sorted too: the API now resolves every commit here to your account, so the credit sticks this time.

One bookkeeping note before the substance. The description at the top has drifted from what the branch actually contains — the CSD geometry insets, the server_seat.c double-free, and the off-screen constraint break are all gone from the diff (the crash fix because it landed as d808223, the other two, I assume, in the rebase). Worth trimming it so the next reader isn't looking for code that isn't there.

Two things I'd like changed before I merge, one more I'd like folded in, and one I've talked myself out of.

1. The view_set_size cache swallows the answer to a ConfigureRequest (src/view.c:189)

The early-out is right for the physics tick, which is what it was asked for, and it does retire the 60 Hz storm. But view_sync_position() has a second caller with a different job. xwl_handle_request_configure calls it not to move the window but to tell the client no — the synthetic ConfigureNotify ICCCM 4.1.5 requires when a request is ignored. The cache compares exactly the fields that a refusal leaves untouched:

• The fullscreen branch (src/view.c:564) exists solely to re-assert the geometry to a game that asked for a different size — the CS2 case in the comment right above it. view->width/height and the position are all unchanged there by construction, so the cache hits and no configure goes out at all. The refusal never reaches the client, and the cfg_denied_w/h guard above it is now rate-limiting a call that does nothing.
• The ordinary branch (src/view.c:573) has the same hole for a client that asks only to move: ev->width/ev->height come back identical, our position is unchanged, cache hit, silence. Before this commit it got a configure carrying our position, which is the "no" it was waiting for.

Cheapest fix is to invalidate before answering — view->last_sync_w = -1; at the top of xwl_handle_request_configure — but I'd rather see the two jobs named apart: view_sync_position() stays cached for the tick, and the reply path gets a forced variant. The distinction is real and it will bite again otherwise.

2. The LOCKED block in pointer_grab_deliver can't be reached (src/server_pointer.c:209)

pointer_grab_deliver has one caller, process_cursor_motion:398. process_cursor_motion has two, handle_cursor_motion:478 and handle_cursor_motion_absolute:515. Both still open with

if (server->active_constraint && !lock_is_active(server)) {
    if (server->active_constraint->type == WLR_POINTER_CONSTRAINT_V1_LOCKED) {
        server_notify_activity(server);
        return;
    }

which this branch leaves in place (server_pointer.c:448, :502). So getting past them with a lock held needs lock_is_active(server) to be true — and then process_cursor_motion:345 returns before line 398. No path arrives at the new block with a LOCKED constraint active.

What worries me more than the dead code is the direction it points. It returns true before the button_count check, so if that early return upstream is ever removed — which is the whole shape we agreed on in the first round — this becomes an unconditional "the pointer is spoken for" that suppresses pointer_update_focus outright, and with it constraints_follow_focus. That is the original hole, re-dug one function further down.

Either drop the hunk and the comment edit at :397 that describes it, or finish the move: take the early return out of both motion handlers and put the guard where focus actually changes, if (view && !locked) server_focus_view(...) inside pointer_update_focus. I'm happy with either — the first keeps the tree honest, the second is the design. What's there now is neither.

3. The absolute-motion path kept the old behaviour (src/server_pointer.c:508)

wlr_region_confine went into handle_cursor_motion only; handle_cursor_motion_absolute still calls constraint_allows_at and drops the event. A tablet, or the pointer a VM hands its guest, therefore still gets the stall you replaced rather than the clamp. 85a0e2d deliberately brought those two paths together for exactly this reason — please apply the same clamp there. constraint_allows_at then has no callers left and can go with it.

4. The stuck grab: taking it as written (src/server_pointer.c:736)

This is the best find in the branch and it is live on main today, independent of everything else here. A GTK client drags its own CSD titlebar → xdg_toplevel.move → handle_request_move → server_start_interactive_move sets FWM_ACTION_MOVE. The press already went out (action was NONE at the time), so button_count is 1; at the release action is no longer NONE, the release is withheld, and the count never comes back down. Since 1727912 that jams pointer_grab_deliver into returning true for every motion, and the client goes on believing its button is held.

To be precise about the damage, because it is worse than "swallows left clicks" and slightly better than permanent: focus-follows-pointer comes back for exactly one motion event each time something else clears pointer focus — the launcher, expo, the ring, the region selector all do — because ptr_surface then no longer matches focused_surface and the grab check falls through. pointer_update_focus runs once, restores the match, and the next motion jams again. wlr_seat_pointer_clear_focus doesn't touch button_count, so nothing ever unsticks it.

I went looking for a hole in button_count > 0 — it doesn't name which button, so on paper a release for a button the compositor claimed and never forwarded would reach the client as a phantom. It doesn't: I disassembled the 0.20 we build against, and wlr_seat_pointer_notify_button walks pointer_state.buttons[] on a release, and returns 0 without ever calling grab->interface->button when the button isn't there or its n_pressed doesn't reach zero. And the condition can't miss a release either — if the client holds the press, the count is at least 1. So it's correct as written, and I'd rather not add bookkeeping to say what the seat already knows.

The one thing I'd ask: the comment explains why we must send the release, but not why it's safe to send one we might not owe. A line saying the seat drops a release for a button it isn't holding would save the next reader the trip through the disassembler.

Since it stands entirely on its own, I'll take this commit ahead of the rest whenever you like — say the word and it goes onto main before the constraint work is finished.

---

Smaller, none of them blocking:

• src/server_pointer.c:732 has trailing whitespace, which git diff --check catches — a little funny given 295fc36.
• src/server_tick.c:1853: int dx = body->x - view->x; truncates, while the scene node is placed from the exact double on the line below. Over a long glide the cursor drifts against the window by a pixel or two, which is the thing the commit sets out to prevent.
• The wlr_region_confine() == false case is still a stall — the else drops the motion, and if the pointer is genuinely outside the region every subsequent motion starts outside it too. Not a regression and not yours to fix here; that's the issue I said I'd open.

Ping me when 1, 2 and 3 are done and I'll merge.

[iluaii]

Taking you up on the offer from my last review: e491d07 is on main as b60ccce, with your authorship on the commit and a cherry picked from line pointing back here. It stands on its own, it fixes a bug that was live on main today, and there is no reason for it to wait on the constraint work.

Two small things I folded in rather than asking you for another round:

• the trailing whitespace on the should_forward line (the two blank-ish lines below it were already on main, so I left those alone — separate cleanup);
• the comment note I asked for. It now reads:

    /* If we sent a press to the client (e.g. they clicked the titlebar), we MUST
     * send the release so the grab completes, even if the compositor took over
     * the drag in the meantime. Otherwise wlr_seat's button_count stays stuck > 0.
     * Sending one we do not owe is harmless: on a release the seat walks its own
     * pointer_state.buttons[] and returns without touching the client if that
     * button is not among the ones it is holding. */

Builds clean against wlroots 0.20, all 18 ctest targets pass.

So when you next rebase, drop e491d07 from the branch — it will either fall out on its own or come back as an empty pick. Everything else is unchanged: points 1 (the view_set_size cache swallowing the ConfigureRequest reply), 2 (the unreachable LOCKED block in pointer_grab_deliver) and 3 (wlr_region_confine in the absolute-motion path) are still what I need before I can merge the rest. No rush — ping me when they are in.