[PATCH xwayland] xwayland: Always update the wl_pointer cursor on pointer focus

Keith Packard keithp at keithp.com
Fri Sep 25 10:13:13 PDT 2015


Jonas Ã…dahl <jadahl at gmail.com> writes:

> The reason I didn't do this was that we'd send duplicate set_cursor
> requests when the cursor actually did change. What the patch does is
> make it so that the path that actually does change the cursor when it
> changes according to the X server always does it when needed in
> Xwayland. I assume we still need to call CheckMotion() on enter to
> actually keep the state up to date anyway.

Ok, slightly annoying, but I assume it will work (at least for now).

> This is what this patch does by introducing the "invalidated" state
> causing ChangeToCursor to ignore that the cursor didn't change.
> mipoiner.c has its own didn't-change-checking which is why there is the
> same type of code added there. Or do you have a suggestion on how to do
> that without adding API (in both events.c and mipointer.c)?

Now you made me go read the code. I think we can safely assume at this
point that essentially every DDX uses mipointer. That means the
redundant checks for cursor changes in events.c are mostly a waste of
time.

How about we change DIX to always call pScreen->DisplayCursor on cursor
changes (and fix the obvious ref count bug that would introduce), and
then you can happily wrap the screen DisplayCursor function to do
whatever you like in terms of getting the cursor displayed.

One suggestion -- call the wrapped function with a NULL cursor and then
with the real cursor when you need to get the cursor displayed for the
entered window. Your DDX would then only set the cursor the second time
through.

I'm sure there are other options. I just like to keep DDX-specific hacks
inside the DDX where possible.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150925/5a2acd6f/attachment.sig>


More information about the xorg-devel mailing list