From: Cole Robinson <crobinso@redhat.com>
To: Takashi Iwai <tiwai@suse.de>, Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] [PATCH] gtk: Keep the pointer within window during input grab
Date: Fri, 11 Apr 2014 17:08:59 -0400 [thread overview]
Message-ID: <534859EB.7010202@redhat.com> (raw)
In-Reply-To: <s5hd2gogfla.wl%tiwai@suse.de>
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
prev parent reply other threads:[~2014-04-11 21:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 12:46 [Qemu-devel] [PATCH] gtk: Keep the pointer within window during input grab Takashi Iwai
2014-04-08 22:46 ` Cole Robinson
2014-04-11 13:07 ` Gerd Hoffmann
2014-04-11 13:28 ` Takashi Iwai
2014-04-11 21:08 ` Cole Robinson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534859EB.7010202@redhat.com \
--to=crobinso@redhat.com \
--cc=aliguori@amazon.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).