[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PGTK-related misconceptions
From: |
Trey Peacock |
Subject: |
Re: PGTK-related misconceptions |
Date: |
Wed, 27 Jul 2022 08:34:27 +0000 |
"Po Lu" <luangruo@yahoo.com> writes:
> That's because the Wayland compositor isn't sending a keymap that makes
> libxkbcommon assign Mod4 to Super. See this bit of gdkkeys-wayland.c:
>
> if (mods & (1 << xkb_keymap_mod_get_index (xkb_keymap, "Super")))
> state |= GDK_SUPER_MASK;
>
> which is called from deliver_key_event and keyboard_handle_modifiers in
> gdkdevice-wayland.c:
>
> seat->key_modifiers = gdk_keymap_get_modifier_state (keymap);
>
> and uses an XKB keymap created in _gdk_wayland_keymap_update_from_fd.
> It is not a bug in GTK, but a bug in the default configuration of the
> Wayland compositor (regardless of what their developers say.)
This section of code is in gdkkeys-x11.c and called from update_keymaps:
mask = 0;
for (j = 0; j < keymap_x11->keysyms_per_keycode; j++)
{
if (syms[j] == GDK_KEY_Meta_L ||
syms[j] == GDK_KEY_Meta_R)
mask |= GDK_META_MASK;
else if (syms[j] == GDK_KEY_Hyper_L ||
syms[j] == GDK_KEY_Hyper_R)
mask |= GDK_HYPER_MASK;
else if (syms[j] == GDK_KEY_Super_L ||
syms[j] == GDK_KEY_Super_R)
mask |= GDK_SUPER_MASK;
}
Which seems like it accepts the GDK_KEY_Super_L/R and subsequently sets
the mask, right? I believe this is the reason why the virtual mask is
recognized when using Xwayland on wlroots based compositors.