-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Every wl_pointer::button
event is followed immediately by a wl_pointer::motion
#1148
Comments
I think the grab has it's values here. But I would challenge that |
It seems in Sway this is handled with Anyway, there are several problems here:
|
Right, so we shouldn't send it.
The necessity should thus be expressed by the Grab-trait or preferrably the grab would somehow emit this event itself, if needed. |
Yeah, the specific grab could call it. Or their could be an associated But this doesn't address the first point: no Though I'm not sure if |
Yeah that is tougher to solve. But the two other grabs that spring directly to my mind are move and resize grabs. And if the application is somehow requesting a valid move, while the pointer is locked, then imo the lock should be lifted. In general we might want to consider pointer grabs breaking locks/constrains. If the pointer is "grabbed" by the compositor, it can't be locked/constraint by a client. (With the ClickGrab being the obvious exception.) Optionally (if we don't want to special case the ClickGrab somehow), a grab could denote, if it should break locks and grabs. And if it doesn't, it shouldn't send motion events. That is somewhat easy to describe in the interface and can probably also be enforced in code. |
Good point. We could disable any active pointer constraints when a grab is activated; though this would have to exclude Moving the |
Oh yeah, and then there's the part where |
Used in `ClickGrab` to prevent `motion` events from occurring with every `button` event. Otherwise, behavior should be unchanged. This matches the argument taken by `KeyboardInnerHandle::unset_grab`. This seems like the simplest solution. It would also be possible to add a method to the `PointerGrab` trait indicating if focus should be restored, but that's complicated since `unset_grab` can't access the grab when it's `Borrowed`, so it would have to add a bool to `GrabStatus::Borrowed`, etc. This still doesn't send a `frame`, but since this takes a serial and a time, it probably will be sent along with other pointer events, and hopefully part of a `frame`. The Wayland spec isn't all that specific about when things can/should be part of a `frame`... Calling `motion` is also incorrect with pointer constraints, but grabs other than `ClickGrab` generally shouldn't exist while a constraint is active. It would be good to enforce that some way. Fixes Smithay#1148.
Used in `ClickGrab` to prevent `motion` events from occurring with every `button` event. Otherwise, behavior should be unchanged. This matches the argument taken by `KeyboardInnerHandle::unset_grab`. This seems like the simplest solution. It would also be possible to add a method to the `PointerGrab` trait indicating if focus should be restored, but that's complicated since `unset_grab` can't access the grab when it's `Borrowed`, so it would have to add a bool to `GrabStatus::Borrowed`, etc. This still doesn't send a `frame`, but since this takes a serial and a time, it probably will be sent along with other pointer events, and hopefully part of a `frame`. The Wayland spec isn't all that specific about when things can/should be part of a `frame`... Calling `motion` is also incorrect with pointer constraints, but grabs other than `ClickGrab` generally shouldn't exist while a constraint is active. It would be good to enforce that some way. Fixes Smithay#1148.
This behavior seems undesirable and incorrect, even if clients normally aren't impacted by absolute motion to the same position. In particular it is an issue with pointer locking, since
wl_pointer::motion
events shouldn't be sent at all.gdb
showsunset_grab
is responsible here. It seems the issue is thatPointerGrab::button
forClickGrab
is callingunset_grab
, which then sends amotion
event.Should a grab really be used here? I guess a
motion
event may be necessary with other types of grabs, but not with this one, since it doesn't block motion events. But it's not clear how to do this. Perhaps wlroots could be worth looking at, since they have somewhat similar mechanisms...With #1126 this
motion
also ends up in the same frame as thebutton
event. Which maybe is correct if it is sent; or maybe it's implicit in the protocol thatmotion
andbutton
are separate event types that need to be in different frames? Though more generally, ifset_grab
andunset_grab
sendmotion
events, those should be followed by aframe
.The text was updated successfully, but these errors were encountered: