diff options
author | Dudemanguy <random342@airmail.cc> | 2021-08-15 09:32:11 -0500 |
---|---|---|
committer | Dudemanguy <random342@airmail.cc> | 2021-08-15 09:45:23 -0500 |
commit | e0df7688f63d57f4f72c99977bd4cedb33e59a71 (patch) | |
tree | 0ee3b9a9022fad2db61fc93dd7cdee37d861d34b /RELEASE_NOTES | |
parent | 0c9e1e34fddb35e9b4205cee4ce6810e4a7388ee (diff) | |
download | mpv-e0df7688f63d57f4f72c99977bd4cedb33e59a71.tar.bz2 mpv-e0df7688f63d57f4f72c99977bd4cedb33e59a71.tar.xz |
wayland: check for xkb state in handle modifiers
Normally in wayland, you receive a keymap event from the compositor
which is what allows the client to setup what is needed for xkb.
However, it turns out that this doesn't occur in the case of virtual
keyboards, such as from wtype, that come from the custom
virtual-keyboard protocol. What happens in this case is that mpv only
receives a keyboard entrance event. According to the wayland protocol
documentation [1], "the compositor must send wl_keyboard.modifiers event
after [the wl_keyboard.enter] event". It is possible for this to occur
before the physical keyboard is properly mapped (i.e: using a virtual
keyboard to start mpv). What this results in is a segfault once
xkb_state_update_mask is called in the modifiers event. The fix is to
simply not always assume we have created the xkb state if we get this
event and check for its existence first. Closes #9119.
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard
Diffstat (limited to 'RELEASE_NOTES')
0 files changed, 0 insertions, 0 deletions