-
Notifications
You must be signed in to change notification settings - Fork 207
wl_seat v10 with compositor key repeat #1773
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
base: master
Are you sure you want to change the base?
Conversation
I fixed the serial generation by pushing the logic up a bit, close to where the backend receives the event. The events go now like:
This means the repeating is global to the seat: switch from one client to the other and repeating continues. If repeating was per-client, then the compositor itself would not receive repeat events without making it look like a client (and I'm not ready for that level of rearchitecting). The good news is I think feels more natural :)
EDIT: I read the spec more carefully and this is not needed. Does this design look right? |
8f73732
to
22bd9b0
Compare
This still relies on unreleased wayland-rs, but I copleted and undrafted it to reflect my confidence. |
|
This brings in the wl_seat protocol v10. Signed-off-by: dcz <[email protected]>
This implements KeyState::Repeat from wayland-protocols seat version 10.
fbf9ae3
to
c380d4d
Compare
Updated, now using all upstream. |
Bump - this is pretty solid I think. |
Is there anything I can do to push this forward? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Drakulix Could you take a look as well? I don't feel confident with merging this without a second opinion.
This adds compositor-side key repeat from the just released wl_keyboard v10.
There are some problems:
Repeat events have the same serialWith the above in mind, I'm not sure if I plugged it in the correct place, so I'm marking this as a draft.