GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
If the compositor sends a keymap that fails on "compilation",
xkb_keymap_new_from_string() returns NULL, which makes xkb_state_new()
crash when assuming there is a keymap.
In these cases, gdk must remain with a xkb_state to handle modifiers/keys
properly, so warn about the invalid keymap string, and keep the previous
keymap (currently initialized to "us")
https://bugzilla.gnome.org/show_bug.cgi?id=735389
The is_modifier field is supposed to be set if the key
would act as a modifier, not if any modifiers are currently
active. To fix this, introduce a private
_gdk_wayland_keymap_key_is_modifier function.
At the same time, make the hardware_keycode field in key
events actually contain the hardware keycode, not a copy
of the keyval.
The GDK model for keymaps expects the keymap object to stay
around and emit a ::keys-changed signal. So, do that. This
should make layout changes work, but it remains untested since
weston does not support layout changes at runtime.
At the same time, plug a memory leak where GdkWaylandKeymap
forgot to free its xkb objects in finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=696339
libxkbcommon has had some changes to its API. However, it now has a
stable release (0.2.0), so this makes the necessary changes, and
replaces all uses of the deprecated API.
Signed-off-by: Ran Benita <ran234@gmail.com>
Review comment: I think the implementation of the vfuncs in gdkkeys-wayland.c
depend on that we're using the keysysm as the hardware keycode. I think that
needs to be evaluated for the future. But for now this patch gives reasonably
complete keyboard input.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
This is then logically associated with the input device since each (keyboard)
input device has its own keymap.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Although GDK expects the keymap to be associated with the display under
Wayland this is really associated with the input device so expose this by
finding the first keyboard device.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Due to changes in the behaviour of the virtual modifiers around MOD1 the
implementation of the map_virtual_modifiers vfunc was mangling the modifiers
and making keybindings not work correctly.
This change updates the implementation to match the X11 implementation's
behaviour.
