You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.
It's not clear what wlroots should do when the compositor decides to change the pointer focus and there are some pressed buttons.
Clients receiving leave will assume buttons have been released. Clients receiving enter won't be aware that some buttons are being pressed. Additionally, the wlroots internal state will still assume some buttons are being pressed.
While wl_keyboard.enter contains an array of currently pressed keys, this isn't the case for wl_pointer.enter.
Related issues:
Dragging a window with its titlebar: pointer.button(pressed) gets sent to the client. Client sends a xdg_toplevel.move request. This starts a grab in the compositor. pointer.leave is sent to the client, the pointer focus is unset. Later on the grab ends. At this point the compositor must send pointer.button(released) so that wlroots state is updated, even if the event isn't sent to any client (NULL pointer focus).
Pointer bindings: pointer.button(pressed) gets sent to the client. Later on the compositor decides this is a pointer binding so it sends pointer.leave. At this point the compositor must send pointer.button(released) so that wlroots state is updated, even if the event isn't sent to any client.
Possible solutions:
Implicitly release all buttons when pointer focus changes.
Implicitly send pressed events to the new surface for all currently pressed buttons when pointer focus changes.
In any case, this requires to track which buttons are pressed in wlroots. We already do this for keyboard keys in wlr_keyboard but not in wlr_seat_keyboard. Not sure tracking buttons in wlr_seat_pointer is a good idea. Or should we track keys in wlr_seat_keyboard instead of wlr_keyboard?
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
Pointer bindings: pointer.button(pressed) gets sent to the client. Later on the compositor decides this is a pointer binding so it sends pointer.leave. At this point the compositor must send pointer.button(released) so that wlroots state is updated, even if the event isn't sent to any client.
This isn't the only way. In Wayfire, I never send the pressed event, and the pointer focus never changes, as this is a one-time action which doesn't change anything.
In addition to `button_count`, we keep track of the current buttons
pressed just as in `wlr_keyboard`.
Add `set_add` and `set_remove` to assist with this. These functions can
only be used with values greater than 0 (such as the button/key masks
for keyboards and pointers).
Partially addresses:
- #1716
- #1593
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's not clear what wlroots should do when the compositor decides to change the pointer focus and there are some pressed buttons.
Clients receiving
leave
will assume buttons have been released. Clients receivingenter
won't be aware that some buttons are being pressed. Additionally, the wlroots internal state will still assume some buttons are being pressed.While
wl_keyboard.enter
contains an array of currently pressed keys, this isn't the case forwl_pointer.enter
.Related issues:
pointer.button(pressed)
gets sent to the client. Client sends axdg_toplevel.move
request. This starts a grab in the compositor.pointer.leave
is sent to the client, the pointer focus is unset. Later on the grab ends. At this point the compositor must sendpointer.button(released)
so that wlroots state is updated, even if the event isn't sent to any client (NULL pointer focus).pointer.button(pressed)
gets sent to the client. Later on the compositor decides this is a pointer binding so it sendspointer.leave
. At this point the compositor must sendpointer.button(released)
so that wlroots state is updated, even if the event isn't sent to any client.Possible solutions:
In any case, this requires to track which buttons are pressed in wlroots. We already do this for keyboard keys in
wlr_keyboard
but not inwlr_seat_keyboard
. Not sure tracking buttons inwlr_seat_pointer
is a good idea. Or should we track keys inwlr_seat_keyboard
instead ofwlr_keyboard
?wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1593
The text was updated successfully, but these errors were encountered: