sway/input/cursor: implement pointer-warp-v1#9147
Conversation
| double lx = event->x + con->pending.content_x - view->geometry.x; | ||
| double ly = event->y + con->pending.content_y - view->geometry.y; | ||
| wlr_cursor_warp(cursor->cursor, NULL, lx, ly); | ||
| wlr_seat_pointer_warp(event->seat_client->seat, event->x, event->y); |
There was a problem hiding this comment.
Do we need to send a pointer frame event here? Or is this unnecessary, or handled elsewhere?
There was a problem hiding this comment.
I was mindlessly copying the zwp_locked_pointer_v1 implementation for pointer warp. I think that implementation does wlr_seat_pointer_warp to not send a motion event to client, since it's inhibited by the spec. The spec for pointer-warp doesn't say the motion event should inhibited though, so I don't think we should do wlr_seat_pointer_warp
| return; | ||
| } | ||
|
|
||
| struct sway_view *view = view_from_wlr_surface(event->surface); |
There was a problem hiding this comment.
This doesn't work for surfaces which aren't views (e.g. layer-shell, ext-session-lock). For xdg_popup, this doesn't account for the offset correctly.
Ideally we'd walk up the surface tree and accumulate delta coordinates. This could be left as a TODO for now.
There was a problem hiding this comment.
The same applies for pointer-constraints too
| double lx = event->x + con->pending.content_x - view->geometry.x; | ||
| double ly = event->y + con->pending.content_y - view->geometry.y; |
There was a problem hiding this comment.
Should we use pending or current here?
There was a problem hiding this comment.
I think pending state is right here, as with zwp_locked_pointer_v1
3 participants
Ref: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5367