From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X3kY8-0007CA-Cd for qemu-devel@nongnu.org; Sun, 06 Jul 2014 07:24:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X3kY3-0002W5-FJ for qemu-devel@nongnu.org; Sun, 06 Jul 2014 07:24:04 -0400 Received: from gate.crashing.org ([63.228.1.57]:34030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X3kY3-0002W1-5l for qemu-devel@nongnu.org; Sun, 06 Jul 2014 07:23:59 -0400 Message-ID: <1404645831.29546.257.camel@pasglop> From: Benjamin Herrenschmidt Date: Sun, 06 Jul 2014 21:23:51 +1000 In-Reply-To: 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> <53B92E16.20604@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 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: Peter Maydell Cc: Alexey Kardashevskiy , Paolo Bonzini , "qemu-devel@nongnu.org" , Alexander Graf , Gerd Hoffmann On Sun, 2014-07-06 at 12:13 +0100, Peter Maydell wrote: > On 6 July 2014 12:08, Alexander Graf wrote > > 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 ;). > > Well, you *can* use the host cursor, but by default you should not > (ie you still need to hide the host cursor and rely on the guest displaying > its own pointer). Well, it depends what you mean by the guest draws its own pointer ... we are in the specific case of cirrusfb HW cursor emulation which Gerd and I are trying to fix. Basically the guest doesn't draw anything. Gerd initial implementation just passes the pixels to the dpy/qemu cursor, but while that probably works fine in absolute mode, it's somewhat busted in relative mode at least with SDL and gtk. The question is whether we can make it work that way (by basically having grab and moving the host cursor) or do we really need to add a layer for painting the cursor on top of the surface. > You should also honour command line -show-cursor > which overrides this to say "don't hide host cursor". Our SDL and Cocoa > UIs get this right, GTK doesn't currently. Cheers, Ben.