On the server, while the cursor is on a client, every physical mouse move
warped the local cursor back to screen center and the tap callback returned
the mouse-move event instead of consuming it. That leaked continuous motion
to whatever local app sat under the centered cursor (e.g. a fullscreen game
or a centered video reacting to the phantom movement).
Capture the mouse the way macOS games do instead: dissociate the hardware
mouse from the cursor in leave() so the cursor freezes and hides, read raw
deltas from the event in onMouseMove(), consume off-screen moves in the tap
callback, and re-associate in enter() (disable() already does via
showCursor()). This retires the center-warp and the "bogus motion" edge
heuristic that only existed to paper over the warp.
fixes: #5871
updateShape() unconditionally recentered the cursor and notified the
server on every call, even mid-churn when no device reports a region
yet. Only touch tracked state once a real region is found, and only
notify the server when the shape actually changed.
On a multi-monitor server the portal reports one input-capture zone per
output. handleZonesChanged added a pointer barrier on every active side of
every zone, including edges that sit on an internal seam between two adjacent
monitors. The portal rejects such a barrier ("adjacent to multiple monitor
edges"), and because a single rejected barrier fails the whole
set_pointer_barriers request, input capture never engaged on multi-monitor
Wayland servers.
Compute the union (bounding box) of all zones first, then add a barrier for a
given side only when that zone edge lies on the outer boundary of the union,
skipping internal seams.
Server aborted with "pure virtual method called" when the bind address
was in use: EiScreen's PortalInputCapture glib thread outlived Arch and
hit its freed vtable. ~EiScreen never deleted m_portalInputCapture, and
a fatal startup threw past cleanupServer(). Fix both.
Add util:CloseApplication entries for deskflow.exe, deskflow-core.exe,
deskflow-server.exe and deskflow-client.exe so Windows Installer's
Restart Manager can shut them down before file replacement. Without
this, in-place upgrades (especially pre-1.24 -> 1.24+, where the
old server/client binaries need removing) hit files-in-use and fall
back to prompting the user for a reboot.
