Clarifying `zwp_locked_pointer_v1` unlock warping behavior with `set_cursor_position_hint`
I'm looking to get a bit of clarification on the behavior of warping during
When unlocking, the compositor may warp the cursor position to the set cursor position hint. If it does, it will not result in any relative motion events emitted via wp_relative_pointer.
Sway implements this behavior by sending a
wl_pointer.motion event, but no
wp_relative_pointer.motion event when warping to the position set via the position hint.
As far as I could tell, this follows the spec. Whenever
wl_pointer.motion should be inhibited, the spec is explicit in saying so.
However, it appears that implementing this behavior has broken some clients (ref). Since the client is sent a motion event on unlock warp, it interprets it as user input and does something unexpected (in the linked case, it swivels the camera).
It seems to me that the "spirit" of not sending relative motion events on unlock is to prevent this sort of behavior. In that case, should the regular motion event also be inhibited on unlocking, so long as a cursor hint is set? (Presumably, if it is set, the application is already keeping track of its own cursor.) Otherwise, it seems like an application would have to track state in order to drop the first motion event after unlocking, which seems unwieldy.