From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1aku-0000ge-Qu for qemu-devel@nongnu.org; Mon, 30 Jun 2014 08:32:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1akn-0000UA-9N for qemu-devel@nongnu.org; Mon, 30 Jun 2014 08:32:20 -0400 Received: from gate.crashing.org ([63.228.1.57]:56170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1akm-0000To-P6 for qemu-devel@nongnu.org; Mon, 30 Jun 2014 08:32:12 -0400 Message-ID: <1404131521.29546.3.camel@pasglop> From: Benjamin Herrenschmidt Date: Mon, 30 Jun 2014 22:32:01 +1000 In-Reply-To: <1404126876.24066.23.camel@nilsson.home.kraxel.org> References: <1402974463.7661.102.camel@pasglop> <1403001900.1614.10.camel@nilsson.home.kraxel.org> <1403003721.7661.148.camel@pasglop> <1403006267.1614.14.camel@nilsson.home.kraxel.org> <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> 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: Gerd Hoffmann Cc: Alexey Kardashevskiy , Paolo Bonzini , "qemu-devel@nongnu.org" , Alexander Graf On Mon, 2014-06-30 at 13:14 +0200, Gerd Hoffmann wrote: > Hi, > > > From what I can tell, we only ever call the cursor drawing callback on > > non-shared surfaces. Should I deduce that the HW cursor emulation simply > > doesn't work when using shared surfaces ? Or is there another path I > > have missed to handle it ? > > Hmm. Looks like hw-cursor-on-shared-surface broken indeed. Need to dig > out a guest which actually uses it & go figure when testing your patch > series ... I don't think I broke it much more than it already was but then I couldn't find a guest using it. I've tried the plain cirrus DDX in X and it didn't have any problem... maybe windows ? > > It makes sense in a way since we never want to draw the cursor in the > > shared framebuffer, but we could probably handle it by having a small > > separate pixman surface which we paint on top of the final render or > > something like that (or link to a host side HW cursor if any) but I > > can't quite see anything in the code. > > There is infrastructure to inform the ui code how the cursor should look > like (grep for "dpy_cursor_define"), so we actually can use the hosts > hardware cursor support. cirrus doesn't use it though. Right. A quick fix would be to add a flag to force always using a shadow surface and set it in cirrus ... I'm not sure anybody will notice the performance difference. My main problem is whatever more complicated than that would require testing and I yet have to find something to run in the guest that uses that cirrus HW cursor. Cheers, Ben. > cheers, > Gerd >