Read and dispatch pending Wayland events to make sure we do not miss a
possible reply from the compositor prior to discard a key repeat.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Key repeat is handled by the X server, but input events need to be
processed and forwarded by the Wayland compositor first.
Make sure the Wayland compositor is actually processing events, to
avoid repeating keys in Xwayland while the Wayland compositor cannot
deal with input events for whatever reason, thus not dispatching key
release events, leading to repeated keys while the user has already
released the key.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762618
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This creates a function that invalidates the current sprite and forces
a sprite image reload the next time the sprite is checked, moving that
logic out of the xwayland sources and allowing the miPointerRec
structure to be removed from the server API.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If data is received during XWayland startup, it will be read early in
InitInput() before the connection data is initialized, causing a crash.
Remove the wayland rountrips from InitInput() as this is done again in
xwl_screen_init() where it seems more appropriate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
The last cursor frame we commited before the pointer left one of our
surfaces might not have been shown. In that case we'll have a cursor
surface frame callback pending which we need to clear so that we can
continue submitting new cursor frames.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
In Wayland, a client (in this case XWayland) should set the cursor
surface when it receives pointer focus. Not doing this will leave the
curser at whatever it was previously.
When running on XWayland, the X server will not be the entity that
controls what actual pointer cursor is displayed, and it wont be notified
about the pointer cursor changes done by the Wayland compositor. This
causes X11 clients running via XWayland to end up with incorrect pointer
cursors because the X server believes that, if the cursor was previously
set to the cursor C, if we receive Wayland pointer focus over window W
which also has the pointer cursor C, we do not need to update it. This
will cause us to end up with the wrong cursor if cursor C was not the
same one that was already set by the Wayland compositor.
This patch works around this by, when receiving pointer focus, getting
the private mipointer struct changing the "current sprite" pointer to
an invalid cursor in order to trigger the update path next time a cursor
is displayed by dix.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
wl_keyboard::enter is the equivalent of FocusIn + KeymapNotify: it
notifies us that the surface/window has now received the focus, and
provides us a set of keys which are currently down.
We should use these keys to update the current state, but not to send
any events to clients.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While we have keyboard focus, the server's xkb code is already locking
and latching modifiers appropriately while processing keyboard
events.
Since there is no guaranteed order between wl_keyboard key and
modifiers events, if we got the modifiers event with a locked or
latched modifier and then process the key press event for that
modifier we would wrongly unlock/unlatch. To prevent this, we ignore
locked and latched modifiers while any of our surfaces has keyboard
focus.
But we always need to set the xkb group index since this might be
triggered programatically by the wayland compositor at any time.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Commit 2172714c changed behavior of capability handling, but it only
solved part of the problem. If Xwayland is launched without a capability
(e.g. no pointer device is connected when Xwayland was spinned up), and
later that capability comes, the device added will not be automatically
initialized. This patch initializes the device when the capability is
reported for the first time, thus avoiding the problem.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=81819
Signed-off-by: Boyan Ding <stu_dby@126.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When grabbed, the slave device is floating, i.e. the master device is NULL.
CheckMotion() isn't happy with NULL. Make sure we pass the right device in,
either the master device when the device is attached, or the device itself
when it is floating.
Reported-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
A DeviceIntPtr with touch valuators is also created in order to deliver
the translated touch events. The lifetime of xwl_touch structs is tied
to the wayland ones, finishing in either wl_touch.up() or wl_touch.cancel()
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This struct holds information about each individual, ongoing touchpoint.
A list of these is held by the xwl_seat.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This was built as a hack for simple Wayland compositors like Weston
which were lazy and didn't want to configure windows server-side when
moved.
Since comboboxes and menus are separate toplevel O-R windows, this hack
breaks input as it needs to be traced normally, not simply sent to the
focused window.
X11 toolkits really do need their windows to be configured correctly
for their O-R windows comboboxes or menus other things, so let's fix
the lazy compositors and remove this.
I have tested this patch with both Weston and Mutter and neither of
them require any changes, and it fixes comboboxes and menus.
If somebody then wants to revert 73698d4, that's fine by me, so we
reduce the amount of API that DDXen have.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
xwayland windows ignored any key repeating settings
advertised by a compositor
v2. don't hardcode version 4 of seat
use AutoRepeatModeOn/Off
v3. use min(version, 4) when binding seat
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
By the time we get here we've already done CloseDownDevices, so on the
second regeneration you get:
Invalid read of size 4
at 0x43402A: RemoveDevice (devices.c:1125)
by 0x427902: xwl_seat_destroy (xwayland-input.c:568)
by 0x42649C: xwl_close_screen (xwayland.c:116)
by 0x4B7F67: CursorCloseScreen (cursor.c:187)
by 0x536003: AnimCurCloseScreen (animcur.c:106)
by 0x539831: present_close_screen (present_screen.c:64)
by 0x43E486: dix_main (main.c:351)
by 0x30D70206FF: (below main) (libc-start.c:289)
Address 0x980e1a0 is 64 bytes inside a block of size 904
at 0x4A07D6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x434158: RemoveDevice (devices.c:1157)
by 0x42F77B: CloseDeviceList (devices.c:1017)
by 0x430246: CloseDownDevices (devices.c:1047)
by 0x43E3EB: dix_main (main.c:333)
by 0x30D70206FF: (below main) (libc-start.c:289)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
In some extreme cases with animated cursors at a high frame rate we
could end up filling the wl_display outgoing buffer and end up with
wl_display_flush() failing.
In any case, using the frame callback to throttle ourselves is the
right thing to do.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fix missing newlines from error string and fix grammar.
Signed-off-by: Robert Ancell <robert.ancell@canonical.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We don't even need to simulate button clicks; it's done automatically.
This also fixes scrolling in Qt5 apps.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Nothing was using it and if anyone had they would've gotten a warning and
noticed that it doesn't actually work. Drop this, it has been unused for years.
Input ABI 22
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Currently, the indexes are off by 4 because of the scroll buttons.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
If something quickly maps and unmaps a window, then we'll immediately
create and destroy the Wayland surface that cooresponds to that
window. If our mouse pointer is over the window when the surface is
created, we'll receive a enter on the window.
Since resource creation and destruction is not synchronous, that
means that the compositor will queue up an event for a resource that's
eventually destroyed. On the client-side, when we receive this message,
we note that the resource isn't allocated, and get a NULL surface in our
enter handler. We immediately try to dereference this, and then crash.
This was caused by running gtkperf while moving the window a lot.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Anytime a capability is first reported, the device is created, but after
that, it is only disabled/enabled.
This is a closer behavior to what Xorg does on VT switch, at the expense
of maybe leaving a dangling "physical" device if a capability goes for good.
Otherwise, any DeviceIntPtr (re)created after server initialization will be
left floating, and bad things happen when the wayland enter event handler
tries to update cursor position based on a floating device.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Started out as an Xorg module to be used from Xorg drivers to let
Xorg run under a wayland server. The idea was to be able to reuse the
2D acceleration from the Xorg driver. Now with glamor being credible,
a better plan is to just make Xwayland its own DDX, similar to Xwin
and Xquartz. This is a much better fit, as much of the code in the
original approach had to hack around Xorg doing Xorg things like take
over the VT, probe input devices and read config files. Another big win
is that Xwayland dosn't need to be setuid root.
The Xwayland support for DRI3, Glamor and render nodes was done by
Axel Davy <axel.davy@ens.fr>, who also did a lot of work on the rebase
to the Xwayland DDX.
Contributions from:
Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Corentin Chary <corentin.chary@gmail.com>
Daniel Stone <daniel@fooishbar.org>
Kristian Høgsberg <krh@bitplanet.net>
Robert Bragg <robert@linux.intel.com>
Scott Moreau <oreaus@gmail.com>
Tiago Vignatti <tiago.vignatti@intel.com>
Giovanni Campagna <gcampagn@redhat.com>
Jonas Ådahl <jadahl@gmail.com>
Ray Strode <rstrode@redhat.com>
Trevor McCort <tjmccort@gmail.com>
Rui Matos <tiagomatos@gmail.com>
Axel Davy <axel.davy@ens.fr>
Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
