Xwayland uses the device private to point to the `xwl_seat`.
Device may be removed at any time, including on suspend.
On resume, if the DIX code ends up calling a function that requires the
`xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random
data.
Make sure the clear the device private data on removal so that we don't
try to use it and crash later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/xorg/xserver/issues/709
xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of
cursor_confinement_window is not NULL, yet there is no code path
that could lead to this.
Remove the test for cursor_confinement_window being set, it's useless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client issues a ConfinePointer wit ha hidden cursor,
Xwayland may translate that as a pointer lock.
However, if the pointer is located on another window at the time,
the request may be ignored, even if the pointer later enters the window.
To avoid that issue, check again if locking the pointer with a hidden
cursor is needed when pointer enters a surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client has an active grab on the pointer, all events are
reported relative to the window with the grab.
For Xwayland, if an X11 client has a grab with a pointer confinement
active, while pointer focus is on another window, motion events should
not be reported to the client with the grab, because that sets the X11
client appart, the events would be reported when the pointer is on any
X11 window but not on Wayland native surfaces.
Therefore, if the pointer is confined on a window and that window
differs from the actual pointer focus window, just pretend we lost
pointer focus to another window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/962
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If a client issues a grab on the pointer while the cursor is on another
X11 window, and then hides the cursor, we may end up locking the pointer
onto that other window.
Then a button click might end up moving the focus away from the window
which issued the grab, leaving the whole setup in a mixed up state.
Typically, if the pointer is on another X11 window, we should not try to
lock the pointer, so that it can be moved back to the window which
actually issues the grab (and hence the pointer confinement). Typically,
this is the same as an X11 client issuing a pointer grab while the
cursor is on another Wayland native window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/962
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Mutter recently added headless tests, and when running those tests the
Wayland compositor runs for a very short time.
Xwayland is spawned by the Wayland compositor and upon startup will
query the various Wayland protocol supported by the compositor.
To do so, it will do a roundtrip to the Wayland server waiting for
events it expects.
If the Wayland compositor terminates before Xwayland has got the replies
it expects, it will loop indefinitely calling `wl_display_roundtrip()`
continuously.
To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for
the returned value from `wl_display_roundtrip()` and fails if it is
negative.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Now that each source and header should be in order, we can safely cleaup
the last remaining bits from the main `xwayland.h` which is not needed
anymore and can be removed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland screen related code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland cursor declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland input declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Over time, Xwayland main source file `xwayland.c` has grown in size
which makes it look cluttered and harder to read.
Move the code dealing with Xwayland window to its own source and header
files.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add support for per client randr-resolution change emulation using viewport,
for apps which want to change the resolution when going fullscreen.
Partly based on earlier work on this by Robert Mader <robert.mader@posteo.de>
Note SDL2 and SFML do not restore randr resolution when going from
fullscreen -> windowed, I believe this is caused by us still reporting the
desktop resolution when they query the resolution. This is not a problem
because when windowed the toplevel window size includes the window-decorations
so it never matches the emulated resolution.
One exception would be the window being resizable in Windowed mode and the
user resizing the window so that including decorations it matches the
emulated resolution *and* the window being at pos 0x0. But this is an
extreme corner case. Still I will submit patches upstream to SDL2
and SFML to always restore the desktop resolution under Xwayland,
disabling resolution emulation all together when going windowed.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On pointer enter notification, Xwayland checks for an existing pointer
warp with a `NULL` sprite.
In turn, `xwl_pointer_warp_emulator_maybe_lock()` checks for an existing
grab and the destination window using `XYToWindow()` which does not
check for the actual sprite not being `NULL`.
So, in some cases, when the pointer enters the surface and there is an
existing X11 grab which is not an ownerEvents grab, Xwayland would crash
trying to dereference the `NULL` sprite pointer:
#0 __GI_raise ()
#1 __GI_abort () at abort.c:79
#2 OsAbort () at utils.c:1351
#3 AbortServer () at log.c:879
#4 FatalError () at log.c:1017
#5 OsSigHandler () at osinit.c:156
#6 OsSigHandler () at osinit.c:110
#7 <signal handler called>
#8 XYToWindow (pSprite=0x0, x=0, y=0) at events.c:2880
#9 xwl_pointer_warp_emulator_maybe_lock () at xwayland-input.c:2673
#10 pointer_handle_enter () at xwayland-input.c:434
Avoid the crash by simply checking for the sprite being not `NULL` in
`xwl_pointer_warp_emulator_maybe_lock()`
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugzilla.redhat.com/1708119
This hasn't done anything besides return TRUE in a long long time.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This prevents multiple scroll events happening for wayland compositors
which send axis values other than 10. For example, libinput will
typically return 15 for each scroll wheel step, and if a wayland
compositor sends those to xwayland without normalising them, 2 scroll
wheel steps will end up as 3 xorg scroll events. By listening for the
discrete_axis event, this will now correctly send only 2 xorg scroll
events.
The wayland protocol gurantees that there will always be an axis event
following an axis_discrete event. However, it does not gurantee that
other events (including other axis_discrete+axis pairs) will not happen
in between them. So we must keep a list of outstanding axis_discrete
events.
Signed-off-by: Scott Anderson <scott@anderso.nz>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Changes the device name from "xwayland-stylus" to "xwayland-tablet stylus".
This doesn't fully address #26 but it goes a little step into making it more
human-readable.
https://gitlab.freedesktop.org/wayland/wayland/issues/26
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_unrealize_window() would use freed xwl_window which can lead to
various memory corruption and crashes, as reported by valgrind:
Invalid read of size 8
at 0x42C802: xwl_present_cleanup (xwayland-present.c:84)
by 0x42BA67: xwl_unrealize_window (xwayland.c:601)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Address 0xf520f60 is 96 bytes inside a block of size 184 free'd
at 0x4C2EDAC: free (vg_replace_malloc.c:530)
by 0x42B9FB: xwl_unrealize_window (xwayland.c:624)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Block was alloc'd at
at 0x4C2FB06: calloc (vg_replace_malloc.c:711)
by 0x42B307: xwl_realize_window (xwayland.c:488)
by 0x541E59: compRealizeWindow (compwindow.c:268)
by 0x57DA40: RealizeTree (window.c:2617)
by 0x580B28: MapWindow (window.c:2694)
by 0x54EA2A: ProcMapWindow (dispatch.c:845)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
This is because UnrealizeTree() traverses the tree from top to bottom,
which invalidates the assumption that if the Window doesn't feature an
xwl_window on its own, it's the xwl_window of its first ancestor with
one.
This reverts commit 82df2ce3
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
status of the third button present on Wacom's new "Pro Pen 3D" stylus.
Treat this button like xf86-input-wacom and send a button 8 event
("navigate back") when received from Wayland.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the Wayland compositor notifies of a new keymap, for the first X11
client using the keyboard, the last slave keyboard used might still not
be set (i.e. “lastSlave” is still NULL).
As a result, the new keymap is not applied, and the first X11 window
will have the wrong keymap set initially.
Apply the new keymap to the master keyboard as long as there's one.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=791383
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The tablet/stylus interfaces reused xwl_seat->focus_window, which
would leave a somewhat inconsistent state of that variable for
wl_pointer purposes (basically, everything) if the pointer happened
to lay on the same surface than the stylus while proximity_out
happens.
We just want the stylus xwl_window to correctly determine we have
stylus focus, and to correctly translate surface-local coordinates
to root coordinates, this can be done using a different variable.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Calling xwl_window_from_window means looping through the window ancestor
chain whenever it is called on a child window or on an automatically
redirected window.
Since these properties and the potential ancestor's xwl_window are constant
between window realization and unrealization, we can omit the looping by
always putting the respective xwl_window in the Window's private field on
its realization. If the Window doesn't feature an xwl_window on its own,
it's the xwl_window of its first ancestor with one.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Xwayland would crash in some circumstances while trying to issue a
pointer locking when the cursor is hidden when there is no seat focus
window set.
The crash signature looks like:
#0 zwp_pointer_constraints_v1_lock_pointer ()
#1 xwl_pointer_warp_emulator_lock () at xwayland-input.c:2584
#2 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2756
#3 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2765
#4 xwl_seat_cursor_visibility_changed () at xwayland-input.c:2768
#5 xwl_set_cursor () at xwayland-cursor.c:245
#6 miPointerUpdateSprite () at mipointer.c:468
#7 miPointerDisplayCursor () at mipointer.c:206
#8 CursorDisplayCursor () at cursor.c:150
#9 AnimCurDisplayCursor () at animcur.c:220
#10 ChangeToCursor () at events.c:936
#11 ActivatePointerGrab () at events.c:1542
#12 GrabDevice () at events.c:5120
#13 ProcGrabPointer () at events.c:4908
#14 Dispatch () at dispatch.c:478
#15 dix_main () at main.c:276
xwl_pointer_warp_emulator_lock() tries to use the surface from the
xwl_seat->focus_window leading to a NULL pointer dereference when that
value is NULL.
Check that xwl_seat->focus_window is not NULL earlier in the stack in
xwl_seat_maybe_lock_on_hidden_cursor() and return early if not the case
to avoid the crash.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=102474
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the compositor has no support for the Xwayland keyboard grab
protocol, there is no need to set-up our keyboard grab handler.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The keyboard grabbing protocol for Xwayland is included in
wayland-protocol 1.9.
Update the wayland-protocol required version in both configure and meson
builds and add support for this new protocol in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The 'tablet_tool_wheel' function for tablet scrolling was added back in
8a1defcc63 but left unimplemented. This commit fills in the necessary
details, using the "clicks" count as the number of discrete scroll up/down
events to send.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The 'tablet_tool_frame' function treats the button masks as though they
are zero-indexed, but 'tablet_tool_button_state' treats them as one-
indexed. The result is that an e.g. middle click event recieved from
Wayland will be sent from the X server as a right-click instead.
Fixes: 773b04748d ("xwayland: handle button events after motion events")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the typical pattern in games of "hide cursor, grab with a confineTo,
warp constantly the pointer to the middle of the window" the last warping
step is actually rather optional. Some games may choose to just set up a
grab with confineTo argument, and trust that they'll get correct relative
X/Y axis values despite the hidden cursor hitting the confinement window
edge.
To cater for these cases, lock the pointer whenever there is a pointer
confinement and the cursor is hidden. This ensures the pointer position
is in sync with the compositor's when it's next shown again, and more
importantly resorts to the relative pointer for event delivery.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the event that xwayland gets launched on a wayland compositor that
doesn't yet have support for wp_tablet_manager, we end up skipping the
initialization of the lists. This is wrong, because regardless of
whether or not a tablet is present we still attempt to traverse these
lists later in xwl_set_cursor(), expecting that if the lists are empty
from no tablet manager that we simply won't execute any loop iterations.
(EE)
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9]
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7f73722545bf]
(EE) 2: Xwayland (xwl_set_cursor+0x9f) [0x429974]
(EE) 3: Xwayland (miPointerUpdateSprite+0x261) [0x4fe1ca]
(EE) 4: Xwayland (mieqProcessInputEvents+0x239) [0x4f8d33]
(EE) 5: Xwayland (ProcessInputEvents+0x9) [0x4282f0]
(EE) 6: Xwayland (Dispatch+0x42) [0x43e2d4]
(EE) 7: Xwayland (dix_main+0x5c9) [0x44c6dc]
(EE) 8: Xwayland (main+0x28) [0x61c523]
(EE) 9: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7f7371e9d401]
(EE) 10: Xwayland (_start+0x2a) [0x4208fa]
(EE) 11: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x28
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Reproduced when trying to run upstream xwayland under fedora 25's weston
package.
Signed-off-by: Lyude <lyude@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hooked up a bit differently to the other tools. Those tools can be static for
all and be re-used. The wacom driver initializes the pad with the correct
number of buttons though and we can't do this until we have the pad done event.
If the tablet is removed and we plug a different one in, we should initialize
that correctly, so unlike the other tools the pad is properly removed and
re-initialized on plug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Each xwl_tablet_tool gets a xwl_cursor, as on wayland each of those
will get an independent cursor that can be set through
zwp_tablet_tool.set_cursor.
However, all tools (and the pointer) share conceptually the same VCP
on Xwayland, so have cursor changes trigger a xwl_cursor update on
every tool (and the pointer, again). Maybe Xwayland could keep track
of the most recent device and only update that cursor to get better
visual results, but this is simpler, and it's going to be odd
anyway...
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
This struct takes away the cursor info in xwl_seat, and has
an update function so we can share the frame handling code
across several xwl_cursors.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Make sure the button events are sent after the motion events into the new
position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Translates Wayland tablet events into corresponding X11 tablet events. As
with the prior commit, these events are modeled after those created by the
xf86-input-wacom driver to maximize compatibility with existing applications.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Creates and maintains the canonical trio of X devices (stylus, eraser,
and cursor) to be shared by all connected tablets. A per-tablet trio
could be created instead, but there are very few benefits to such a
configuration since all tablets still ultimately share control of a
single master pointer.
The three X devices are modeled after those created by xf86-input-wacom
but use a generic maximum X and Y that should be large enough to
accurately represent values from even the largest currently-available
tablets.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
The wp_tablet_seat interface provides us with notifications as tablets,
tools, and pads are connected to the system. Add listener functions and
store references to the obtained devices.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
If we're notified about the existence of the wp_tablet_manager interface,
we bind to it so that we can make use of any tablets that are (or later
become) available. For each seat that exists or comes into existance at
a later point, obtain the associated tablet_seat.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
keyboard_check_repeat() fetches the XWayland seat from the
dev->public.devicePrivate do do its thing.
If a key event is sent programmatically through Xtest, our device is the
virtual core keyboard and that has a dev->public.devicePrivate of NULL,
leading to a segfault in keyboard_check_repeat().
This is the case with "antimicro" which sends key events based on the
joystick buttons.
Don't set the checkRepeat handler on the VCK since it cannot possibly work
anyway and it has no effect on the actual checkRepeat intended functionality.
Bugzilla: https://bugzilla.redhat.com/1416244
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
During the InitInput() phase, the wayland events get dequeued so we
can possibly end up calling dispatch_pointer_motion_event().
If this occurs before xwl_seat->focus_window is set, it leads to a NULL
pointer derefence and a segfault.
Check for xwl_seat->focus_window in both pointer_handle_frame() and
relative_pointer_handle_relative_motion() prior to calling
dispatch_pointer_motion_event() like it's done in
pointer_handle_motion().
Bugzilla: https://bugzilla.redhat.com/1410804
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Sometimes, Xwayland will try to use a cursor that has just been freed,
leading to a crash when trying to access that cursor data either in
miPointerUpdateSprite() or AnimCurTimerNotify().
CheckMotion() updates the pointer's cursor based on which xwindow
XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
to fake a crossing to the root window when the pointer has left the
Wayland surface but is still within the xwindow.
But after an xwindow is unrealized, the last xwindow used to match the
xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
not return the same xwindow.
To avoid this issue, update the last_xwindow based on enter and leave
notifications instead of xwl_xy_to_window(), and check if the xwindow
found by the regular miXYToWindow() is a child of the known last
xwindow, so that multiple consecutive calls to xwl_xy_to_window()
return the same xwindow, being either the one found by miXYToWindow()
or the root window.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Vít Ondruch <vondruch@redhat.com>
Tested-by: Satish Balay <balay@fastmail.fm>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Commits 816015648f and
fee0827a9a made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.
wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.
This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.
On ProcessDeviceEvent() we still need to deactivate X grabs if needed
for KeyReleases.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The definition by the manual is:
calloc(size_t nmemb, size_t size)
Swap the arguments of calloc() calls to be the right way around.
Presumably this makes no functional difference, but better follow the
spec.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not needed anymore now that mipointer exposes an API for that,
miPointerInvalidateSprite()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().
The (simplified) backtrace goes as follow:
(gdb) bt
#0 GetTouchEvents() at getevents.c:1892
#1 QueueTouchEvents() at getevents.c:1866
#2 xwl_touch_send_event() at xwayland-input.c:652
#5 wl_closure_invoke() from libwayland-client.so.0
#6 dispatch_event() from libwayland-client.so.0
#7 wl_display_dispatch_queue_pending() from libwayland-client.so.0
#8 xwl_read_events() at xwayland.c:483
#9 ospoll_wait() at ospoll.c:412
#10 WaitForSomething() at WaitFor.c:222
#11 Dispatch() at dispatch.c:412
#12 dix_main() at main.c:287
#13 __libc_start_main() at libc-start.c:289
#14 _start ()
The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.
Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.
Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pointer enter event coordinates are surface relative and we need them to
be screen relative for pScreen->SetCursorPosition().
https://bugzilla.gnome.org/show_bug.cgi?id=758283
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Emulate pointer warps by locking the pointer and sending relative
motion events instead of absolute. X will keep track of the "fake"
pointer cursor position given the relative motion events, and the
client warping the cursor will warp the faked cursor position.
Various requirements need to be met for the pointer warp emulator to
enable:
The cursor must be invisible: since it would not be acceptable that a
fake cursor position would be different from the visual representation
of the cursor, emulation can only be done when there is no visual
representation done by the Wayland compositor. Thus, for the emulator
to enable, the cursor must be hidden, and would the cursor be displayed
while the emulator is active, the emulator would be destroyed.
The window that is warped within must be likely to have pointer focus.
For example, warping outside of the window region will be ignored.
The pointer warp emulator will disable itself once the fake cursor
position leaves the window region, or the cursor is made visible.
This makes various games depending on pointer warping (such as 3D
first-person shooters and stategy games using click-to-drag-map like
things) work.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Translate grabbing a pointer device with confineTo set to a window into
confining the Wayland pointer using the pointer constraints protocol.
This makes clients that depend on the pointer not going outside of the
window region, such as certain games and virtual machines viewers, to
function more properly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If there was an relative pointer motion within the same frame as an
absolute pointer motion, provide both the absolute coordinate and the
unaccelerated delta when setting the valuator mask.
If a frame contained only a relative motion, queue an absolute motion
with an unchanged position, but still pass the unaccelerated motion
event.
If the wl_seat advertised by the compositor is not new enough, assume
each relative and absolute pointer motion arrives within their own
separate frames.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Wait until wl_pointer.frame with dispatching the pointer motion event,
if wl_pointer.frame is supported by the compositor. This will later be
used to combine unaccelerated motion deltas with the absolute motion
delta.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Generating relative and absolute movement events from the same input
device is problematic, because an absolute pointer device doesn't
expect to see any relative motion events. To be able to generate
relative pointer motion events including unaccelerated deltas, create a
secondary pointer device 'xwayland-relative-pointer', and use that for
emitting relative motion events.
Signed-off-by: Krzysztof Sobiecki <sobkas@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Put device class initialization in init_[device_class](xwl_seat) and
releasing in release_[device class](xwl_seat). The purpose is to make
it easier to add more type of initialization here later, without making
the function too large.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Will be used for getting unaccelerated motion events and later for
relative motions used by a pointer warp emulator.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The way we map the touch absolute device to screen coordinates can't
work across wl_output mode and geometry events. Instead, set up
a fixed coordinate space, and transform touch events according to
the screen coordinate space as they happen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
The checks in xwayland's XYToWindow handler pretty much assumes that the
sprite is managed by the wl_pointer, which is not entirely right, given
1) The Virtual Core Pointer may be controlled from other interfaces, and
2) there may be other SpriteRecs than the VCP's.
This makes XYToWindow calls return a sprite trace with just the root
window if any of those two assumptions are broken, eg. on touch events.
So turn the check upside down, first assume that the default XYToWindow
proc behavior is right, and later cut down the spriteTrace if the
current device happens to be the pointer and is out of focus. We work
our way to the device's lastSlave here so as not to break assumption #1
above.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Since xwayland's initial commit we have had a check to not process
wayland modifier events while one of our surfaces has keyboard focus
since the normal xkb event processing keeps our internal modifier
state up to date and if we use the modifiers we get from the
compositor we mess up that state.
This was slightly changed in commit
10e9116b3f to allow the xkb group to be
set from the wayland event while we have focus in case the compositor
triggers a group switch.
There's a better solution to the original problem though. Processing
queued events before overriding the xkb state with the compositor's
allows those events to be sent properly modified to X clients while
any further events will be modified with the wayland modifiers as
intended.
This allows us to fully take in the wayland modifiers, including
depressed ones, which fixes an issue where we wouldn't be aware of
already pressed modifiers on enter.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Emitting a LeaveNotify event every time the pointer leaves an X11 window
may confuse focus follow mouse mode in window managers such as
mutter/gnome-shell.
Keep the previously found X window and compare against the new one, and
if they match then it means the pointer has left an Xwayland window for
a native Wayland surface, only in this case fake the crossing to the
root window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This partially reverts commit c1565f3.
When the pointer moves from an X11 window to a Wayland native window,
no LeaveNotify event is emitted which can lead to various unexpected
behaviors like tooltips remaining visible after the pointer has left the
window.
Yet the pointer_handle_leave() is called and so is the DIX CheckMotion()
but since the pointer enters a Wayland native window with no other
Xwayland window matching, DoEnterLeaveEvents() does not get invoked and
therefore no LeaveNotify event is sent to the X11 client at the time the
pointer leaves the window for a Wayland native surface.
Restore the XYToWindow() handler in xwayland-input that was previously
removed with commit c1565f3 and use that handler to pretend that the
pointer entered the root window in this case so that the LeaveNotify
event is emitted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96437
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The call to 'InitButtonClassDeviceStruct' which initializes the pointer
buttons only results in the first three buttons being created due to a
hardcoded '3'. In order to expose all the buttons defined in the
btn_labels array, we subtitute 'NBUTTONS' in its place.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Substitute a few errant tab characters with eight spaces to conform to the
prevailing style.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This partially revert commit 984be78
The rountrip in Xwayland's InitInput() is unlikely the culprit for the
crash reported in bug 95337, even though it's triggered from
InitInput().
Startup goes like this:
xwl_screen_init()
xwl_output_create()
wl_display_roundtrip()
InitInput()
wl_display_roundtrip()
ConnectionInfo initialized
What happens in bug 95337 is that some output data is already available
when we reach InitInput()'s wl_display_roundtrip() and therefore we end
up trying to update the ConnectionInfo's data from RR routines before
ConnectionInfo is actually initialized.
Removing the wl_display_roundtrip() from InitInput() will not fix the
issue (although it would make it less lileky to happen), because
xwl_screen_init() also does a wl_display_roundtrip() after creating the
output, so the race that led to bug 95337 remains.
However, re-setting the xwl_screen->expecting_event to 0 again in
InitInput() still doesn't seem right. so this part is not restored
(thus a partial revert).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
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>
Olivier Fourdan
Hans de Goede
Adam Jackson
Scott Anderson
Peter Hutterer
Jason Gerecke
Carlos Garnacho
Roman Gilg
Lyude
Rui Matos
Pekka Paalanen
Jonas Ådahl
Krzysztof Sobiecki
Keith Packard
Daniel Stone
Boyan Ding
Jasper St. Pierre
Marek Chalupa
Robert Ancell
Dima Ryazanov
Kristian Høgsberg