System is running Arch Linux with the following locally-compiled packages:

gnome-control-center	3.24.2+22+g2bebdf11b
gnome-shell		3.24.3
gtk3			3.22.17+5+g32919a4a02
mutter			3.24.4
nautilus		3.24.2+1+gaab979bbd
gnome-settings-daemon	3.24.3

Fox Xwayland, can you check with xeerver git master? Carlos had landed a few fixes for tablets in xserver git master that are not in Xwayland 1.19.

(In reply to Jason Gerecke from comment #0)
> When using a Wacom tablet for navigation around a GNOME desktop in a Wayland
> session, the pen/puck cursor is often not properly updated as it moves over
> various UI elements. For example, when entering an Xwayland window, the
> cursor may change to a resize indicator at the frame, and be left that way

Different causes :).

Assuming you're running Xwayland with zwp_tablet support in master, that would be down down to Xwayland not picking the right zwp_tablet_tool to emulate the VCP. If the cursor is set on wl_pointer instead or just not set on the tablet tool, that'll result in the last known cursor remaining set, which is the resize handles from mutter.

This is totally expected though if you're not running a Xwayland that supports zwp_tablet, as per the protocol mutter expects a zwp_tablet_tool.set_cursor request in reply to the proximity_in event, so it never updates the tool cursor as it doesn't get one.

> after entering the main area of the window. Or, in a pure GTK3 application
> like gnome-control-center, the cursor may need to switch from a regular
> mouse pointer to a hand but doesn't do so at the proper time.

Ok, and I noticed a few gotchas triggered by GtkLinkButton :), attaching a few patches here fixing generic cases, and GtkLinkButton specifically.

Created attachment 356368 [details] [review]
gdkwindow: Update cursor for tablet tools in the window

This check must be done explicitly on Wayland as the master device for
tablet tools differ from the Core Pointer. This ensures that whenever a
tablet tool is inside a window and the cursor is programmatically changed,
it will be visually updated too.

Created attachment 356369 [details] [review]
wayland: Clear tablet tool cursor on proximity out

This ensures that the tablet tool will get the cursor updated even if it
happens to fall within the same window again on the next proximity in.

Created attachment 356370 [details] [review]
gtklinkbutton: Set cursor on button's event window

Setting the cursor on the widget window (i.e. the parent widget's) is
finicky because the cursor needs to be updated on crossing events, and
will yield the wrong result for other master devices that happen to be
in other areas of the same parent widget's window.

Just set it always on the event window created by the GtkButton parent
class. That window was causing the crossing events, so the rectangle
that gets the hand cursor set will be the same size, and we don't need
to track pointer crossing state that way.

(In reply to Carlos Garnacho from comment #3)
> Assuming you're running Xwayland with zwp_tablet support in master, that
> would be down down to Xwayland not picking the right zwp_tablet_tool to
> emulate the VCP. If the cursor is set on wl_pointer instead or just not set
> on the tablet tool, that'll result in the last known cursor remaining set,
> which is the resize handles from mutter.
> 

I'm having trouble getting the master branch of xorg-xserver to build on my system, but I see this using a version of 1.19.3 with most of the tablet-related patches applied on top (all of the original zwp_tablet patches, but not much else). I don't see any changes to the wl_pointer cursor when this occurs, so sounds like the latter.

Ah I see, then it falls on the "no zwp_tablet support" case, totally expected :). FWIW, it's also the same with clients failing to call wl_pointer.set_cursor, on mutter and weston, the last cursor remains set. It can be seen just launching a client from a terminal, freezing it with ctrl-z and hovering it.

I guess mutter could set a more appropriate cursor if no zwp_tablet supporting client is underneath, maybe the "forbidden sign" one, since input will be broken anyway... Feel free to file a bug for that.

(In reply to Carlos Garnacho from comment #8)
> Ah I see, then it falls on the "no zwp_tablet support" case, totally
> expected :). FWIW, it's also the same with clients failing to call
> wl_pointer.set_cursor, on mutter and weston, the last cursor remains set. It
> can be seen just launching a client from a terminal, freezing it with ctrl-z
> and hovering it.
> 
> I guess mutter could set a more appropriate cursor if no zwp_tablet
> supporting client is underneath, maybe the "forbidden sign" one, since input
> will be broken anyway... Feel free to file a bug for that.

My prior comment must have been confusing... I *do* have the zwp_tablet patches (running `xinput list` shows "xwayland-stylus" and friends, and `xinput test-xi2` reports proper pressure-sensitive events) but *still* see the stale cursor when entering an xwayland window.

As for the patch set posted, so far things are looking good :) Restricting myself to GTK3 applications for the moment, cursors now seem to be well-behaved.

I do notice that if I hover over an element with one particular cursor (e.g. a text field and it's "I" beam), bring the pen out of prox, and then bring it back into prox over an element with a different cursor (e.g. most anywhere else), I see the "old" cursor momentarily flash before the correct cursor replaces it. Oddly, this doesn't happen when bringing the pen back into prox over the desktop. This seems like its triggered by a different bug, however.

(In reply to Jason Gerecke from comment #9)
> (In reply to Carlos Garnacho from comment #8)
> > Ah I see, then it falls on the "no zwp_tablet support" case, totally
> > expected :). FWIW, it's also the same with clients failing to call
> > wl_pointer.set_cursor, on mutter and weston, the last cursor remains set. It
> > can be seen just launching a client from a terminal, freezing it with ctrl-z
> > and hovering it.
> > 
> > I guess mutter could set a more appropriate cursor if no zwp_tablet
> > supporting client is underneath, maybe the "forbidden sign" one, since input
> > will be broken anyway... Feel free to file a bug for that.
> 
> My prior comment must have been confusing... I *do* have the zwp_tablet
> patches (running `xinput list` shows "xwayland-stylus" and friends, and
> `xinput test-xi2` reports proper pressure-sensitive events) but *still* see
> the stale cursor when entering an xwayland window.

Doh, I clearly misunderstood you. And also my comment about cursor workings wasn't that much accurate... xwayland indeed has to pick one tool/pointer device to send VCP events from, but cursors should be just set on any pointing device on enter/proximity_in.

AFAICS xwl_tablet_tool_set_cursor() should be called anytime a tool enters proximity on a X window, I see a couple of early returns at https://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland/xwayland-cursor.c#n178 that might result in unapplied cursor though...

(In reply to Jason Gerecke from comment #10)
> I do notice that if I hover over an element with one particular cursor (e.g.
> a text field and it's "I" beam), bring the pen out of prox, and then bring
> it back into prox over an element with a different cursor (e.g. most
> anywhere else), I see the "old" cursor momentarily flash before the correct
> cursor replaces it. Oddly, this doesn't happen when bringing the pen back
> into prox over the desktop. This seems like its triggered by a different
> bug, however.

Hmmm, yeah, against mutter probably. It should also unset the cursor on proximity out, so the cursor is invisible until .set_cursor() is gotten.

Pushed the patches to gtk-3-22, and will do too on master after adapting the linkbutton patch.

Attachment 356368 [details] pushed as 18eeaf7 - gdkwindow: Update cursor for tablet tools in the window
Attachment 356369 [details] pushed as b53a6fb - wayland: Clear tablet tool cursor on proximity out
Attachment 356370 [details] pushed as 0daf796 - gtklinkbutton: Set cursor on button's event window

(In reply to Jason Gerecke from comment #10)
> I do notice that if I hover over an element with one particular cursor (e.g.
> a text field and it's "I" beam), bring the pen out of prox, and then bring
> it back into prox over an element with a different cursor (e.g. most
> anywhere else), I see the "old" cursor momentarily flash before the correct
> cursor replaces it. Oddly, this doesn't happen when bringing the pen back
> into prox over the desktop. This seems like its triggered by a different
> bug, however.

FWIW, https://git.gnome.org/browse/mutter/commit/?id=26fa7b8