From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X3kIr-0004Yf-Db for qemu-devel@nongnu.org; Sun, 06 Jul 2014 07:08:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X3kIj-0006Xe-Sy for qemu-devel@nongnu.org; Sun, 06 Jul 2014 07:08:17 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55095 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X3kIj-0006XE-Id for qemu-devel@nongnu.org; Sun, 06 Jul 2014 07:08:09 -0400 Message-ID: <53B92E16.20604@suse.de> Date: Sun, 06 Jul 2014 13:08:06 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1402974463.7661.102.camel@pasglop> <1403040734.7661.173.camel@pasglop> <1403090315.13406.3.camel@nilsson.home.kraxel.org> <1403096614.7661.208.camel@pasglop> <1403170570.22530.5.camel@nilsson.home.kraxel.org> <1403329021.4587.78.camel@pasglop> <1403403026.4587.108.camel@pasglop> <1404126876.24066.23.camel@nilsson.home.kraxel.org> <1404131521.29546.3.camel@pasglop> <1404202838.24066.52.camel@nilsson.home.kraxel.org> <53B270CD.7080907@suse.de> <53B271EE.4030308@redhat.com> <1404205639.24066.58.camel@nilsson.home.kraxel.org> <53B27D25.4030603@redhat.com> <1404213329.24066.64.camel@nilsson.home.kraxel.org> <1404213827.29546.58.camel@pasglop> <1404292780.29546.90.camel@pasglop> <1404303120.7258.10.camel@nilsson.home.kraxel.org> <1404613171.29546.211.camel@pasglop> <1404625798.29546.214.camel@pasglop> <1404629182.29546.224.camel@pasglop> <1404630327.29546.225.camel@pasglop> <1404631363.29546.232.camel@pasglop> <1404641621.29546.253.camel@pasglop> In-Reply-To: <1404641621.29546.253.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , Gerd Hoffmann Cc: Alexey Kardashevskiy , Paolo Bonzini , "qemu-devel@nongnu.org" On 06.07.14 12:13, Benjamin Herrenschmidt wrote: > On Sun, 2014-07-06 at 17:22 +1000, Benjamin Herrenschmidt wrote: >> - With SDL, the cursor quickly goes bonkers, starts jumping around all >> over the place, I'm not sure what exactly is going on here. It starts ok >> but as soon as one does a too fast movement, it's dead. > At least this one also happens with gtk and appears to be the guest (NT4) > "warping" the cursor to the edges of the screen as soon as you start moving > too quickly. I'm not quite sure what's going on yet, so far I've seen us > send reasonable deltas down. I *suspect* it might have to do with NT's > own mouse acceleration scheme. > > The way we do the relative mouse stuff, we more/less assume that the diff > we send down gets applied "as is". It's not and thus we warp which causes > funny artifacts and when it gets too big, things get nasty inside NT4 itself > as far as I can tell (but I may well have missed something). > > The problem is that when using relative mouses, we can't really assume that > there is any relationship between the absolute position of the host cursor > vs. the guest cursor, we should only operate in deltas and even then, we > probably want to dampen them to compensate for the guest own acceleration. The guest's own acceleration can easily be non-linear, so we can't really tell. However, FWIW we basically have 2 modes 1) absolute pointing device (usb tablet for example or vmmouse) 2) relative pointing device In case 1, we can keep using the host cursor, and just tell the guest where exactly the cursor is in absolute coordinates. This works very well with VNC too ;). In case 2, we can't tell anything at all. We can calculate the delta and hope for the best. That's why with any backend that supports it, we enable mouse grabbing here. In mouse grabbing mode we behave like any game that may do whatever it likes with the mouse delta information. > But that means that the guest HW cursor is never quite where the host cursor > is. So unless the guest draws its own (or something like VNC can draw one), > we have a problem. VNC can explicitly draw the host cursor at specific locations IIRC. You can just send a packet where the cursor is at the moment. I don't know about SDL or GTK+ though. > I'm thinking that for relative mouse, we should probably draw a cursor ourselves > by moving / drawing the cursor pixmap on top of the display pixmap at the UI > backend (gtk/SDL) level... Or am I missing a big part of the puzzle ? Can't we just always draw it ourselves with a second surface on top of our normal guest screen? Then we can make the "real cursor" for GTK+ / SDL / VNC be a 100% alpha cursor as soon as we enable this self-drawn surface and can expose hardware pointers that the respective backend couldn't support. For example, IIRC VNC only supports 1-bit cursors. We certainly want more fancy ones :). Alex