From: John Haxby <john.haxby@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Xen 3.4.x and request-abs-pointer
Date: Tue, 06 Jul 2010 09:19:48 +0100 [thread overview]
Message-ID: <4C32E724.4000107@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1007051731190.17029@kaball-desktop>
On 05/07/10 17:41, Stefano Stabellini wrote:
> On Mon, 5 Jul 2010, John Haxby wrote:
>
>> On 05/07/10 16:45, Stefano Stabellini wrote:
>>
>>> That patch was recently reverted because it was the wrong fix:
>>>
>>>
>>>
>> Rats.
>>
>> Back to my previous attempt then which seemed a little less elegant: the
>> idea was that I would initially register the pointer as relative but
>> check in the first call to xenfb_mouse_event() and if I had guessed
>> wrong, remove the existing mouse handler and add a new one with
>> registered as absolute. If the mouse turns out to be absolute, we miss
>> the very first pointer event but this doesn't seem to be much of an
>> issue because everything will be sorted out on the next mouse event (the
>> various pieces of code that are interested in whether or not the mouse
>> is enabled seem to be OK about switching from relative to absolute).
>>
>> Before I commit a patch to electrons are the any obvious flaws in that
>> approach?
>>
>>
>
> I think that solution is not very elegant besides it doesn't fix the
> basic issue that is on qemu side.
>
Yeah, you're right. It sucks. That's what comes of writing down
something random just before you go home for the day.
> The proper fix would be to add a new hook in qemu like suggested
> in the previous email:
>
>
>> In order to do that properly we need a new hook in qemu xen_backend: we
>> should probably rename the current connect hook to initialise and create
>> a new connect hook that would be implemented by xenfb to read
>> request-abs-pointer.
>>
> Basically we need a new callback from xen_backend.c on
> XenbusStateConnected.
> The current "connect" hook can be called on both XenbusStateInitialised
> and XenbusStateConnected so it doesn't suit our needs.
> I suggest to rename the current "connect" hook to "initialised", and
> create a new "connect" hook that is called only on XenbusStateConnected.
> In the xenfb.c implementation of the new connect hook you can read
> request-abs-pointer and be sure that it was previously set by the guest.
>
>
Sounds reasonable.
jch
prev parent reply other threads:[~2010-07-06 8:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-05 15:22 Xen 3.4.x and request-abs-pointer John Haxby
2010-07-05 15:45 ` Stefano Stabellini
2010-07-05 16:27 ` John Haxby
2010-07-05 16:41 ` Stefano Stabellini
2010-07-06 8:19 ` John Haxby [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=4C32E724.4000107@oracle.com \
--to=john.haxby@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.