Bug 1544442

Description of problem:

This is a follow up to an earlier bug, originally reported for Fedora 25. Things got a lot better with xwayland and Wacom tablets in Fedora 27, since it was not usable at all on the two previous releases. Unfortunately, there are still some issues.

When I plug my Wacom tablet in my machine, I get two cursors: one for my laptop's touchpad and another that is controlled by my tablet's stylus. That's fine, but the behaviour of the cursor icon is not consistent and the Wacom-controlled cursor often becomes invisible and non-functional.

To fix the sudden invisibility, I have to quickly move my stylus around and take the invisible cursor over the top bar. After one or two times I do this, the cursor becomes visible again, usually with a crosshair icon.

The cursor icon also changes with poor consistency. While the touchpad-controlled cursor icon gets the expected changes (like the crosshair icon, resize window, hand for moving files...), the stylus icon does not change consistently. Sometimes, the windows also seem to lose focus only to the stylus controlled cursor, so I have to click with the touchpad cursor, click again with the stylus cursor and repeat this process a few times until the window starts recognizing my stylus' cursor again.

Sometimes, if I have the two cursors over the same window and I perform an action with the stylus-controlled one (normally, a click), the action gets activated on the place where the touchpad-controlled cursor is.

For one example, I can't get to click with the stylus-controlled cursor on the window menu from Gnome Terminal.

Dragging folders to the Bookmarks session on a Nautilus window also gets unexpected results when using the sylus-controlled cursor.

Another example has occurred while I was writing this bug report: I couldn't click on this textarea html element without first clicking a few times over my Firefox's window elements until it get 'focus' to the correct cursor. It wasn't a single click. Only after 3 or 4 clicks the window focus was correctly assigned to one cursor.

How reproducible:
Must have a Wacom Tablet for reproducing this bug

Steps to Reproduce:
1. Log into a Wayland-managed Gnome session in Fedora 27
2. Plug a USB Wacom Tablet
3. Perform click and drag actions on some windows with the two cursors. In my experience, web browsers (Firefox and Chromium), nautilus and gnome terminal are enough to repeat these issues. 

Actual results:
Non-recognized click and drag actions, wrong cursor icons.

Expected results:
Normal click and drag actions with both cursors.

--- Additional comment from Olivier Fourdan on 2017-12-04 15:15:18 CET ---

I see similar issues with The GIMP, using the tablet makes the mouse completely unresponsive (until input focus is set on anohter toplevel and back). Seems 100% reproducible.

--- Additional comment from Olivier Fourdan on 2017-12-04 15:27:26 CET ---

Here's what I can reproduce quite reliably:

1. run gtk3-demo event_axes with the x11 backend:

   $ GDK_BACKEND=x11 gtk3-demo --run=event_axes

2. Move the mouse pointer on the demo window, the axis show up, source is "xwayland-pointer:13"

3. move the stylus pointer over the same window, the axis show upo, source is "xwayland-stylus:13"

4. lift up the stylus out of proximity while keeping the cursor within the window

5. try to move the mouse pointer, the axis do not move, click inside the demo window, nothing happens.

Additional data:

$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-stylus:13                      	id=9	[slave  pointer  (2)]
⎜   ↳ xwayland-eraser:13                      	id=10	[slave  pointer  (2)]
⎜   ↳ xwayland-cursor:13                      	id=11	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:13                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:13            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:13                    	id=8	[slave  keyboard (3)]

--- Additional comment from Olivier Fourdan on 2017-12-08 17:28:51 CET ---

Note: moving to xorg-x11-server for Xwayland (Wayland, the package or rather libwayland is just an IPC library).

Fix has been pushed in Xserver for this:
https://patchwork.freedesktop.org/patch/191698/