On 04/11/2014 09:28 AM, Takashi Iwai wrote: > At Fri, 11 Apr 2014 15:07:34 +0200, > Gerd Hoffmann wrote: > >> On Di, 2014-04-08 at 14:46 +0200, Takashi Iwai wrote: >>> The current code shows annoying behavior where the X pointer can move >>> out of the window during the input grab in the absolute mode. Due to >>> this, the pointer in qemu window looks as if frozen until the real >>> (invisible) X pointer comes back to the window again. >>> >>> For avoiding such an unexpected lag, this patch limits the pointer >>> movement only within the qemu window during the input grab in the >>> absolute mode. When the pointer goes out, it's moved back to the >>> boundary again. >> >> At least at X11 level it is possible to simply confine the pointer to a >> certain window (see "man XGrabPointer"). Then you don't have to warp >> the pointer. > > I have such a vague memory, too, and tried it before my patch, but > couldn't manage to make it working. The man page describes the > pointer event processing, but it doesn't describe how the pointer > moves. It's more than a decade when I played with it, so I really > forget how these things work... > >> Warping the pointer in absolute mode has ugly effects (see >> 2bda66028b4962c36d4eabe2995edab12df93691). > > What exact effect do we see? The commit log doesn't give much clue, > and I didn't notice any issue with gtk and qxl, so far. >
With an F20 guest at least, qxl + gtk was unusable, as described here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02678.html The mouse would just warp off the UI. However your patch still preserves the do_mouse_set short circuiting when in absolute mode, so that issue doesn't resurface. The -7/-3 pixel offset I mention in the above mail might come into play, but I actually can't verify it with my F20 vm, since initiating a pointer grab in absolute mode with qxl makes the pointer entirely invisible. Thought it was maybe https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg01627.html but that didn't help any. - Cole
