From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Haxby Subject: Re: Xen 3.4.x and request-abs-pointer Date: Tue, 06 Jul 2010 09:19:48 +0100 Message-ID: <4C32E724.4000107@oracle.com> References: <4C31F8C8.8090800@oracle.com> <4C320804.3090109@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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