The events are routed through a new slave device with type
GDK_SOURCE_TOUCHSCREEN, minimal tracking of touches is done
to keep the state for each of those.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
The master pointer/keyboard pair should never disappear or be
inconsistent. The seat capabilities are now reflected through
slave devices, those may come and go freely as the seat
capabilities change. This also enables adding further capabilities
to handle eg. touch.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
Lots of code, including dragging code in GtkWindow, use these
fields. Setting them to 0 causes lots of strange and weird bugs.
Use the same "hack" from query_device_state of just using
win_x / win_y for now. We'll convert this to the proper fake root
coordinate system used by get_root_coords in the next commit.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
Under Wayland we don't know the absolute position of the device but there are
some API calls that expect to get an root window position. Previously we were
not assigning any value to these out parameters potentially leaving the values
undefined.
This change returns the current surface relative position of the device.
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.
We always emit direction-changed when we get a new keymap, but
for state changes, we compare old and new direction and only
emit the signal when the direction actually changes.
Instead of maintaining the init refcount in regular event handlers that can
fire in case of hotplug or mode changes, use a dedicated sync callback
to wait for roundtrips.
We use a ref-count mechanism to track whether parts of the init sequence
still needs round trips to receive remaining initial state. Typically
we need a couple of roundtrips total to get the global list, then the
input and output configurations, but with the ref-count we avoid making
global assumptions like that.
https://bugzilla.gnome.org/show_bug.cgi?id=696340
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
These might be candidates for a future settings interface; until
then, we use GSettings directly. Note again that we are careful
to avoid a dependency on GNOME schemas.
Key repeat under X is not affected by modifiers. And on some systems
(e.g my Thinkpad), NumLock is permanently on, rendering key repeat
nonfunctional. This commit changes the Wayland backend to do
key repeat regardless of modifiers.
http://bugzilla.gnome.org/show_bug.cgi?id=695497
Commit 0d9d808217 fixed the hotspot issue,
but commit f2cc52fddd then optimized away
cursor changes a little too aggressively. We always need to set the
cursor on enter. Make sure we clear the current cursor on leave so we
don't think it's already set on the next enter.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
wl_pointer.set_cursor is rejected if the serial number doesn't match
the enter serial number for the wl_pointer. We passed the right serial
number when setting the cursor surface in response to the enter event.
Later set_cursor requests fail, but we can still attach new buffers to
our cursor surface, which is why the cursor changed, but the hotspot
didn't update. Clicking in the decoration results in a leave/enter pair
which triggers wl_pointer.set_cursor with the right serial. That's why
clicking the decoration sets the right cursor.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
We need to pass the delta between the old and new hotspot
when attaching the new cursor surface, to keep the hotspot
at the same position. We can't deal with this in the compositor,
since the set_cursor call already overwrites the old hotspot,
so the information is lost by the time the attach happens.
Unfortunately, we can't query the initial hotspot from
the compositor, so the first cursor change will make the
hotspot jump.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
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>
