virtual_keyboard: Release keys on destroy#2697
virtual_keyboard: Release keys on destroy#2697tadeokondrak wants to merge 1 commit intoswaywm:masterfrom
Conversation
36026b2 to
01b5f97
Compare
|
Hm, but maybe this applies to physical keyboards as well? What happens if you hold a key and disconnect your keyboard? Same applies to the keyboards for the Wayland/X11 backends. Maybe this logic should be part of |
It doesn't keep repeating, I'm not sure what handles this.
Is the parent Wayland compositor leaving a key pressed when removing the keyboard capability from a seat something that clients should handle?
It only has one seat, so keyboards can't be removed during runtime. |
01b5f97 to
ccd6b4f
Compare
|
|
||
| void wlr_keyboard_init(struct wlr_keyboard *keyboard, | ||
| const struct wlr_keyboard_impl *impl); | ||
| void wlr_keyboard_release_keys(struct wlr_keyboard *keyboard); |
There was a problem hiding this comment.
Maybe this shouldn't be a public function. Not sure what to do instead, though.
| } | ||
|
|
||
| void wlr_keyboard_destroy(struct wlr_keyboard *kb) { | ||
| if (kb == NULL) { |
There was a problem hiding this comment.
Could wlr_keyboard_release_keys be called inside wlr_keyboard_destroy instead?
That way it could be private. [edit: I see this was suggested above as well]
There was a problem hiding this comment.
That would be best indeed. I'm not a fan of having keyboard-specific stuff inside the common code.
There was a problem hiding this comment.
wlr_keyboard_destroy is called after the destroy signal on the wlr_input_device is emitted.
If the keys are released after that signal, the original issue isn't fixed anymore.
|
I wonder if instead we should keep the status quo and make it so destroying a keyboard implicitly releases all keys. |
|
Superseded by #2918 |
Fixes #2034.