On 24/03/14 06:52, Yves-Alexis Perez wrote: > I'm not completely sure it's the right solution here. I mean, it might > be the wisest short-term one, but it'll also break XInput2 features. I > guess not much people already use them and I'm not sure how well they > work, but I guess the best way to fix the issue would be to use XInput2 > API correctly everywhere, so the “right” cursor is always found. > > I'm not sure what that means concerning “global” cursors like the > notification one (I guess it has no reason to be defined until we arrive > at the root window), but I guess that's something which should be > discussed at the GTK level. > > Regards, >
Why should calling XDefineCursor "break" XInput2 features? As I understand it, the core protocol cursor defined by XDefineCursor is used as a fall-back whenever there is no device-specific cursor defined; it doesn't impede device-specific cursors from being used. Now, the internal behaviour of gdk_window_set_cursor seems to enumarate all of the available input devices, and sets the device cursor individually for each device - This might make sense in an application window, but I'm not sure its what you really want here. It has the nasty effect of detaching all of the device cursor definitions on the root window from the core cursor - and that detachment effectively remains permanent throughout the user session which gets launched on the display. By way of comparison, I've been trying to work out what the gdm3 display manager does with the cursor. The gdm3 greeter runs the Metacity window manager, which appears to call XDefineCursor on initialisation (looks like it does this separately for every screen on a multi-screen setup). Maybe some Gnome guru could confirm this. Metacity also appears to toggle the busy cursor using XDefineCursor, in the same way as the Xfce window manager does. So good-old XDefineCursor hasn't gone out of fashion. I can't see anything here which suggests that setting separate device cursors for every device on the root window at startup is a good idea! ;-) Best wishes, Ken. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
