Comment 17 for bug 1024482

On 02/24/2013 03:25 AM, swiftgeek wrote:
> So i guess that the reason of why webkit/gtk-builder are working is a
> crazy race condition :]

I think the reason that lightdm-webkit-greeter is not affected is that
it links against GTK2, not GTK3. Both GTK2 and GTK3 define a
gdk_window_set_cursor() function: the GTK3 version uses XInput's
problematic XIDefineCursor function, while the GTK2 version does not.

As for the patch to lightdm-gtk-greeter: I think that works because with
the patch, gdk_window_set_cursor() is no longer called on the root
window, it's only called on windows created by the greeter itself.
These windows disappear once the greeter exits, so any device cursor
definitions would disappear with them.

It's not a problem when a program sets device cursors on it's own
windows: that only affects those windows and the program (presumably)
knows how to deal with them. It's when something sets a device cursor
on the *root* window that we have problems, because lots of programs
need to work with the root window and many of them don't use XInput2.

> Would it be possible to patch gdk_window_set_cursor() and include fixed one in greeters (eg. as __gdk_window_set_cursor() )
> and post fixed one on gnome's bugzilla?

Yeah, I'll take a shot at a patch. If we end up modifying the greeters,
though, I think it would be simpler to replace the call to
gdk_window_set_cursor() with a call to XDefineCursor(). The
implementation of gdk_window_set_cursor() is gnarlier than you might
think, since it deals with alternative windowing systems (Win32,
Wayland, HTML5, etc.) and stuff.