Most keyboards today do not have a dedicated Meta key. Instead, they may
have a Win key (Windows logo, Penguin logo, etc), which is delivered by
evdev as e.g. KEY_LEFTMETA, but then mapped by libxcbcommon to LWIN
via the default config from xkeyboard-config:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/keycodes/evdev#L203
and then mapped further to Super_L
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/pc#L24
which is the key symbol that we in Qt see.
As it is common to use Qt::Key_Meta in keyboard shortcuts, it would
be useful if the Win key resulted in key events as if a dedicated Meta
key had been pressed.
This is already something we do for X11, where we consume the events
from xkbcommon, but then use X-specific heuristics to determine if
there is an actual Meta key, and if not, we assume Super/Hyper is Meta.
For plain xkbcommon, we don't have enough information to do the same
kind of heuristics, so we've previously defaulted to not treating
Super/Hyper as Meta. But, as the above xkeyboard-config configs show,
a saner default would be to assume that there is no Meta key, and do
the same mapping as we do for X11 for all consumers of xkbcommon,
such as Wayland and EGLFS.
This does mean that clients that were relying on dedicated Super or
Hyper keys producing Qt::Key_Super or Qt::Key_Hyper will no longer
see these keys being pressed.
[ChangeLog][QtGui][Linux/Wayland][Linux/Yocto] Super ("Win" key) and
Hyper keys will no longer produce the corresponding Qt::Key_Super or
Qt::Key_Hyper key events, but will instead be mapped to Qt::Key_Meta
and result in Qt::MetaModifier being set.
Fixes: QTBUG-62102
Change-Id: Ied4c8b60a0639e87116ab70c7e40d4082f52b18d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
610bafdfc5