<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Cursors for Wacom tablets are not always updated correctly under Wayland" href="https://bugzilla.gnome.org/show_bug.cgi?id=785375#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Cursors for Wacom tablets are not always updated correctly under Wayland" href="https://bugzilla.gnome.org/show_bug.cgi?id=785375">bug 785375</a> from <a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> Carlos Garnacho</a> <pre>(In reply to Jason Gerecke from <a href="show_bug.cgi?id=785375#c9">comment #9</a>) > (In reply to Carlos Garnacho from <a href="show_bug.cgi?id=785375#c8">comment #8</a>) > > 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 <a href="https://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland/xwayland-cursor.c#n178">https://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland/xwayland-cursor.c#n178</a> that might result in unapplied cursor though... (In reply to Jason Gerecke from <a href="show_bug.cgi?id=785375#c10">comment #10</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>