From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: RFC: drop frontend support for relative pointer Date: Tue, 13 Oct 2009 18:05:28 +0200 Message-ID: <87ocobcm9j.fsf@pike.pond.sub.org> References: <87vdirw2d8.fsf@pike.pond.sub.org> <20091007200124.GD2270@redhat.com> <87skduoxbo.fsf@pike.pond.sub.org> <87d44ss5su.fsf@pike.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: (Jean Guyader's message of "Mon\, 12 Oct 2009 22\:18\:06 +0100") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jean Guyader Cc: "xen-devel@lists.xensource.com" , "Daniel P. Berrange" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Jean Guyader writes: > 2009/10/12 Markus Armbruster : >> Jean Guyader writes: >> >>> 2009/10/12 Jean Guyader : >>>> 2009/10/8 Markus Armbruster : >>>>> Stefano Stabellini writes: >>>>> >>>>>> On Wed, 7 Oct 2009, Daniel P. Berrange wrote: >>>>>>> That's good to know - stubdom was one area I was concerned about. T= o the >>>>>>> best of my knowledge the only backend that ever sent relative mouse= events >>>>>>> was the old PVFB we had in Fedora 6 which was the original code bef= ore >>>>>>> the eventual merge into official xen-devel trees. So official repos= have >>>>>>> always defaulted to absolute mode. =C2=A0Hopefully no one out there= has gone >>>>>>> and re-implemented the PVFB backend in any other fork of Xen and dr= opped >>>>>>> ABS mode or made REL the default ??? >>>>>>> >>>>>>> IMHO if ABS mode is able to work correctly, then there's absolutely= no >>>>>>> benefit in having a REL mode at all, so its best deleted / removed. >>>>>> >>>>>> I guess keeping around unused code doesn't make much sense but I was= just >>>>>> being cautious, given that for example XCI is currently using relati= ve >>>>>> coordinates so they are not dead just yet. >>>>> >>>>> Just to avoid misunderstandings: >>>>> >>>>> * Does XCI set feature-abs-pointer in xenstore? >>>>> >>>>> * If it does, does it read request-abs-pointer from xenstore? >>>>> >>>>> * Under what circumstances (if any) does it send XENKBD_TYPE_MOTION, = and >>>>> =C2=A0under what circumstances (if any) does it send XENKBD_TYPE_POS? >>>>> >>>> >>>> Hi, >>>> >>>> I just checked and we have feature-abs-pointer and request-abs-pointer >>>> set to 1 xenstore. >>>> The function we use to inject mouse/keyboard event in the guess is >>>> kbd_mouse_event and it works with xenkbd. >>>> >>> >>> I checked into the code and we force xenkb to use relative coordinates. >>> We use that because in XCI the hardware mouse on the host is generally >>> setup to send relative coordinates, and we do a 1 to 1 map for the >>> mouse/keyboard What if the physical pointer device uses absolute events? Do you pass those on 1:1, too? >> Thanks for your help. =C2=A0To sum up: >> > >> * The XCI backend advertizes absolute pointers (feature-abs-pointer set >> =C2=A0in xenstore) >> > > Yes. > >> * The frontend asks for it (request-abs-pointer set in xenstore) >> >> * Regardless, the XCI backend sends only relative coordinates (event >> =C2=A0type XENKBD_TYPE_POS). >> >> Correct? >> >> If yes, then this works more by accident than by design :) >> > > Yep it does work, that is wrong in our code. > I didn't know about this xenstore protocol when I hacked it up. > > Here is the nasty patch: > http://git/git/xenclient/ioemu-pq.git/tree/master/fix-imobile-mouse Broken link, please check. >> By setting feature-abs-pointer, the backend offers absolute events. >> Reneging on this offer after the frontend accepted it is a bug. >> > > Yep, I belive there is a bug somewhere. > >> What now? =C2=A0Could XCI upgrade to absolute? =C2=A0If not, could it at= least >> stop offering feature-abs-pointer? >> > I'll fix that inside our code. If you want to pass on absolute events received from your physical pointer device, then things become a bit more complicated. You need to offer feature-abs-pointer, obviously. But if the frontend declines (request-abs-pointer off), you can't pass on absolute events, you must convert to relative. > I don't really thing we could use absolute because we do graphic > device pass through with PV guest and the resolution we have on the > screen is completely decouple with the fb resolution. I figure the real solution is to decouple the PV pointer/keyboard from the PV framebuffer, so you can configure the pointer independently, and don't have to drag a PV framebuffer along, just to get a PV pointer/keyboard.