WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen 3.4.x and request-abs-pointer

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 3.4.x and request-abs-pointer
From: John Haxby <john.haxby@xxxxxxxxxx>
Date: Tue, 06 Jul 2010 09:19:48 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 06 Jul 2010 01:21:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1007051731190.17029@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C31F8C8.8090800@xxxxxxxxxx> <alpine.DEB.2.00.1007051639570.17029@kaball-desktop> <4C320804.3090109@xxxxxxxxxx> <alpine.DEB.2.00.1007051731190.17029@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5
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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>