window-rule: add block-pointer-constraints to suppress pointer-lock activation

[joshsymonds]

Summary

Adds a block-pointer-constraints window-rule (Option<bool>) that
suppresses activation of zwp_pointer_constraints_v1 constraints for
matching windows. Both Locked and Confined variants are suppressed
unconditionally — the rule is opt-in per window, so apps that
legitimately need pointer-constraints (games, drawing tablets, 3D
modelers) are unaffected unless explicitly matched.

Motivation

Some clients request a pointer-lock as part of a tooltip / annotation /
overlay UI surface that users don't actually want to engage when the
cursor merely crosses it — the constraint locks the cursor in place
until pointer focus moves away (which from a user's perspective looks
like "the cursor is stuck"). A per-window opt-out preserves the
protocol for its intended uses while letting users disable it for
specific surfaces.

Concrete motivating case: Zoom's annotate_toolbar overlay (a small
floating toolbar that appears during screen-sharing-with-annotation)
requests a pointer-lock on hover. Users only want to interact with the
toolbar deliberately, but on niri the lock activates whenever the
cursor crosses the overlay's region.

Implementation

• Schema (niri-config/src/window_rule.rs): new
  block_pointer_constraints: Option<bool> field on WindowRule
  adjacent to block_out_from, with the standard
  #[knuffel(child, unwrap(argument))] annotation.
• Resolution (src/window/mod.rs): same field on
  ResolvedWindowRules, last-Some-wins resolution in compute().
• Gate (src/niri.rs): Niri::maybe_activate_pointer_constraint()
  short-circuits when the constrained surface's root toplevel matches a
  rule with this flag set. The check is placed inside the
  with_pointer_constraint callback after the constraint-present
  early-return, so the no-constraint fast path that runs on every
  pointer motion is unchanged. Root-surface resolution uses the existing
  Niri::find_root_shell_surface helper (popups + subsurfaces are
  handled correctly).
• Test: parser test in niri-config/src/lib.rs extends the existing
  window-rule fixture to cover the new property round-tripping.
• Wiki: new #### block-pointer-constraints section in
  docs/wiki/Configuration:-Window-Rules.md between block-out-from
  and opacity, with the motivating Zoom example.

Design notes

• Activation-time gate, not bind-time refusal. The protocol still
  binds and the client's request still arrives at smithay; niri just
  never calls constraint.activate(). Well-behaved clients gate
  relative-motion mode and similar features on the constraint being
  active, so they degrade gracefully to normal absolute-motion input.
• Both variants, unconditionally. A Confined constraint with a
  sufficiently large region produces the same user-visible "cursor
  stuck" pattern as Locked; suppressing both keeps the rule's
  semantics predictable. A future enhancement could split this into an
  enum if a real use case demands variant-specific control.
• Per-window, opt-in. Global pointer-constraint suppression would
  break games, drawing tablets, and Blender-style middle-drag
  interactions; per-window keeps the rule narrowly scoped.

Test plan

• cargo build --workspace clean
• cargo test -p niri-config passes (parser test exercises the new field, wiki-parses test confirms the KDL example parses)
• cargo clippy --workspace --all-targets -- -D warnings clean
• cargo fmt --check --all clean
• Deployed live on Linux/Wayland; config parses, rule resolves on the motivating window
• End-to-end cursor-suppression on the motivating app (Zoom annotate_toolbar) — verification in progress on next session

[YaLTeR]

Thanks, however in this case it sounds like the app is buggy and should fix its behavior.

[joshsymonds]

Maybe, but I think my chances of getting Zoom to do this are pretty low! No worries if you don't want to accept this though.