- 24 Apr, 2021 1 commit
-
-
- 18 Aug, 2020 1 commit
-
-
This can happen e.g. with weston's headless backend. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit e33453f9)
-
- 20 Jul, 2020 3 commits
-
-
When a slave device causes the master virtual pointer device to change device types, the device's private data pointer (device->public.devicePrivate) is also changed to match the type of the slave device. This can be a problem though, as tablet pad devices will set the device's private data pointer to their own xwl_tablet_pad struct. This can cause us to dereference the pointer as the wrong type, and result in a segfault: Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault. wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792 792 va_start(ap, opcode); (gdb) bt 0 wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792 1 0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0, hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized out>) at /usr/include/wayland-client-protocol.h:4610 2 xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at xwayland-cursor.c:137 3 0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>, screen=<optimized out>, cursor=<optimized out>, x=<optimized out>, y=<optimized out>) at xwayland-cursor.c:249 4 0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:468 5 miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410 6 0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740, pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206 7 miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at mipointer.c:194 8 0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168 9 0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197 10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30, cursor=0x5610b4b35740) at events.c:938 11 0x00005610b28ec99f in WindowHasNewCursor (pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362 12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0, vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc, client=client@entry=0x5610b4b2c900) at window.c:1561 13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900) at dispatch.c:746 14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497 15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68, envp=<optimized out>) at main.c:276 16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>, argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at ../csu/libc-start.c:308 17 0x00005610b27ae96e in _start () at cursor.c:1064 Simple reproducer in gnome-shell: open up an Xwayland window, press some tablet buttons, lock and unlock the screen. Repeat if it doesn't crash the first time. So, let's fix this by registering our own device-specific private key for storing a backpointer to xwl_tablet_pad, so that all input devices have their private data pointers set to their respective xwl_seat. Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Lyude Paul <lyude@redhat.com>
(cherry picked from commit ba0e789b) -
When running with a weston session without a pointer device (thus with the wl_seat not having a pointer) xwayland pointer warping and pointer confining should simply be ignored to avoid crashes. Signed-off-by:
Sjoerd Simons <sjoerd@collabora.com> (cherry picked from commit d35f6833)
-
Olivier Fourdan authored
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:
-
- 29 May, 2020 1 commit
-
-
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:
Roman Gilg <subdiff@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 785e5906)
-
- 05 Jun, 2019 1 commit
-
-
Olivier Fourdan authored
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:
-
- 04 Oct, 2018 2 commits
-
-
Olivier Fourdan authored
So we do not lose subpixel precision in Xwayland. Suggested-by:
-
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:
-
- 18 Apr, 2018 1 commit
-
-
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:
-
- 25 Jan, 2018 1 commit
-
-
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:
-
- 19 Dec, 2017 1 commit
-
-
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:
-
- 06 Dec, 2017 1 commit
-
-
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:
-
- 13 Sep, 2017 1 commit
-
-
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>
-
- 05 Sep, 2017 1 commit
-
-
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:
-
- 04 Sep, 2017 1 commit
-
-
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:
-
- 01 Aug, 2017 1 commit
-
-
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:
-
- 12 Jun, 2017 2 commits
-
-
The 'tablet_tool_wheel' function for tablet scrolling was added back in 8a1defcc 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: -
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: 773b0474 ("xwayland: handle button events after motion events") Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by:
-
- 07 Jun, 2017 1 commit
-
-
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:
-
- 04 May, 2017 1 commit
-
-
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:
-
- 28 Apr, 2017 9 commits
-
-
Peter Hutterer authored
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:
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:
-
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:
-
Peter Hutterer authored
Make sure the button events are sent after the motion events into the new position. Signed-off-by:
-
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: -
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: -
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: -
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: -
Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by:
-
- 01 Mar, 2017 2 commits
-
-
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:
-
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:
-
- 07 Feb, 2017 1 commit
-
-
Peter Hutterer authored
Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by:
-
- 30 Nov, 2016 1 commit
-
-
Olivier Fourdan authored
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:
Vít Ondruch <vondruch@redhat.com> Tested-by:
Satish Balay <balay@fastmail.fm> Reviewed-by:
-
- 29 Nov, 2016 1 commit
-
-
Commits 81601564 and fee0827a 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:
-
- 25 Nov, 2016 1 commit
-
-
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:
-
- 18 Nov, 2016 1 commit
-
-
Not needed anymore now that mipointer exposes an API for that, miPointerInvalidateSprite() Signed-off-by:
-
- 26 Oct, 2016 2 commits
-
-
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:
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:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
-
- 05 Oct, 2016 1 commit
-
-
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:
-
