summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2021-08-15 09:32:11 -0500
committerDudemanguy <random342@airmail.cc>2021-08-15 09:45:23 -0500
commite0df7688f63d57f4f72c99977bd4cedb33e59a71 (patch)
tree0ee3b9a9022fad2db61fc93dd7cdee37d861d34b /DOCS
parent0c9e1e34fddb35e9b4205cee4ce6810e4a7388ee (diff)
downloadmpv-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 'DOCS')
0 files changed, 0 insertions, 0 deletions