Focus does not follow mouse when using tablet (among other misbehaviors)

[florentc]

Version 1.2-aa8fe584 (Dec 17 2019 'master')
Default config file

When focus_follows_mouse is set, a window is expected to get focus when hovered by the cursor. It works when moving the cursor with a regular touchpad or mouse. It does not when using the pen of a Wacom Intuos S Tablet. The cursor moves over the unfocused window but its focus status is unchanged (or it happens after a delay depending on the application). Both native and xwayland clients are affected. All the input device are attached to the same default seat.

Steps

1. Open a nautilus client using dmenu
2. Press CTRL+n to open another. The new client, on the right, is focused.
3. Approach the pen close to the right half of the tablet: the cursor spawns on the already focused window.
4. Translate the pen to the left half: the cursor moves over the client on the left but it remains unfocused (undesired behavior).

Here is the debug trace: https://gist.github.com/florentc/ad8655f13207be7b6626fca5b8b9b379

• When using a mouse or touchpad, the client is immediately focused
• Sometimes, the hovered client gets focused but after a small delay whereas it is instantaneous using a mouse or touchpad

Additional remarks

I have noticed several other misbehaviors I suspect share the same cause:

• in Chromium (xwayland) the shape of the cursor rarely changes to reflect links or text fields when moved using the pen
• in pcmanfm (gtk3) the right click menu opens where the cursor used to be the last time it was moved with a regular mouse instead of where it appears to be after being moved using the pen
• in many gtk3 applications (including nautilus), the cursor may flicker when moved using the pen and right click menus (when triggered using the pen) might fail to open
• borderless gtk3 floating windows with client side decoration cannot be dragged by the pen: they stay in place
• floating windows with sway titlebars can be dragged using the pen but the window does not follow the mouse during the movement (like when moving them using a regular mouse or touchpad), it gets displaced instantly once the pen is lifted

Shall I submit a new issue for each one of the above?

It is as if the cursor moved using the tablet were not the same as the cursor moved by classic devices although all the input devices are attached to the same seat.

I have detailed this issue because it is the easiest to reproduce among a bunch of misbehaviors that make it hard for now to go full tablet and get rid of regular pointing devices, which is impractical.

I am willing to provide additional information or perform other experiments if needed.

[Ongy]

It is as if the cursor moved using the tablet were not the same as the cursor moved by classic devices

That's exactly what's going on in the background. The visual is reused, but all events are separate.

Some of the issues you list are application bugs. The chromium one might be Xwayland, unsure.

The CSD dragging one is probably a sway bug, though I'd have to invesitage.
The sway-decoration dragging is clearly a sway bug.

[florentc]

Thank you for your interest in the issue.

Note that none of these issues happened in sway 1.2 (with basic tablet support), including the chromium issue. They are all unfortunate regressions that have been introduced along with the new "full tablet support" (pressure, etc) between 1.2 and 1.4.
In gnome wayland, there are no issues with CSD dragging nor with chromium.

Back when opening this issue, I tried to add calls to transaction_commit_dirty() in several functions related to cursor.c which seemed to improve responsiveness of the focus update when moving the mouse using the tablet. Removing calls to transaction_commit_dirty() generalized the main issue (focus does not follow mouse) to regular pointing devices (mouse/trackpad). Maybe this helps. I had a hard time understanding the big picture of the event loop. I would be happy to help working on fixing the issues.

[Xyene]

I just ran into this issue too, with a Huion 420 on latest master. I've recorded a video of the focus issues (something about a picture being worth a thousand words): https://drive.google.com/open?id=1WO89fVGy1QRmfXA0STaLCeN_mqDt9PFE

I can reproduce this behaviour with at least Wayland Firefox and gnome-tweaks. I am unable to mess up focus in kitty.

It seems (this is in the recording) that moving through the "border" of a window slowly will always make the focus be passed correctly. If you quickly swipe past it, it seems often the focus is not switched.

Also, sometimes Firefox just dies while clicking around with the pen (almost the same stacktrace as swaywm/wlroots#2062), without the having to unplug. Unsure if these issues are related, but thought it'd be worth mentioning in case they are.

Thread 1 "firefox-bin" received signal SIGSEGV, Segmentation fault.
0x00007ffff65a8b4f in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
(gdb) bt full
#0  0x00007ffff65a8b4f in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#1  0x00007ffff4ae88ee in ffi_call_unix64 () at /lib/x86_64-linux-gnu/libffi.so.6
#2  0x00007ffff4ae82bf in ffi_call () at /lib/x86_64-linux-gnu/libffi.so.6
#3  0x00007ffff5bb528d in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#4  0x00007ffff5bb1ac9 in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#5  0x00007ffff5bb2f94 in wl_display_dispatch_queue_pending () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#6  0x00007ffff65b1884 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x00007ffff6551940 in gdk_display_get_event () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x00007ffff65b15a2 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#9  0x00007ffff5636f2e in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff56371c8 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff563725c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007fffefd063ca in  () at /opt/firefox/libxul.so
#13 0x00007fffefd065dd in  () at /opt/firefox/libxul.so
#14 0x00007ffff0196ce2 in  () at /opt/firefox/libxul.so
#15 0x00007fffefbce3a6 in  () at /opt/firefox/libxul.so
#16 0x00007fffefbf808b in  () at /opt/firefox/libxul.so
#17 0x00007ffff039225f in  () at /opt/firefox/libxul.so
#18 0x00007ffff109bd34 in  () at /opt/firefox/libxul.so
#19 0x00007fffef0e53f3 in  () at /opt/firefox/libxul.so
#20 0x00007ffff168e1fe in  () at /opt/firefox/libxul.so
#21 0x00007ffff169091c in  () at /opt/firefox/libxul.so
#22 0x00007fffef1632af in  () at /opt/firefox/libxul.so
#23 0x00005555555b87a5 in _start ()

Some more detail that might help narrow things down... if:

• the cursor is currently over a window that was not given focus correctly
• the pen is touching the tablet
• the pen is turned off and on twice or thrice

...then the cursor disappears, though you can still interact with the app with an invisible cursor. This cursor-disappearing behaviour never happens when repeating these instructions over a window that has focus.

I was also able to make the situation worse by playing around with transaction_commit_dirty calls. At first glance, a120d4c seems to suggest that focus is performed by calls to transaction_commit_dirty. In particular, I don't immediately see a call to it in any descendant of handle_tablet_tool_position.