From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svq3N-0003cB-I3 for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:30:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svq3D-0003kD-Pn for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:30:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svq3D-0003k8-Hj for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:30:23 -0400 Message-ID: <50168C68.9010103@redhat.com> Date: Mon, 30 Jul 2012 16:30:16 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com> <1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com> <1343649267.21647.44.camel@pasglop> <501676D7.3010504@redhat.com> <878ve11j70.fsf@codemonkey.ws> In-Reply-To: <878ve11j70.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 07/30/2012 04:18 PM, Anthony Liguori wrote: > Avi Kivity writes: > >> On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote: >>>> >>>> > >>>> > We can also make the fbdev/fbcon driver do the swapping in SW, but it's >>>> > a relatively unusual code path and I don't think it works properly with >>>> > X, I don't think it can be made to work properly with the generic X KMS >>>> > at this point. >>>> > >>>> > Now, cirrusdrmfb is already specific to the qemu cirrus variant in >>>> > several ways, I wouldn't mind keeping it that way and if we "fix" the >>>> > endianness model, maybe having a "hidden" register to flip it back to >>>> > it's current mode of operation that cirrusdrmfb would use... >>>> >>>> That's possible, but why not go all the way to qxl? >>>> >>>> That will give you better graphics performance with no need to hack. >>> >>> Well, qxl is pretty awful from what I can see so far. I'm more tempted >>> to continue improving qemu-vga, adding a virtio transport, and maybe >>> adding a way to tunnel spice into it if that makes sense but so far, >>> that's stuff was designed for Windows as far as I can tell and is pretty >>> horrible whatever way you look at it... >> >> Let's balkanize some more then? > > Minor improvements to stdvga actual help qxl (presumably). qxl still > provides a vga interface which is used when guest drivers aren't > available. The premise is that guest drivers will be used, otherwise you may as well stay with stdvga. > It's not clear to me why it doesn't enable VBE but presumably if it did, > then accelerations could be mapped through VBE. I believe the idea is that you don't want to map the framebuffer into the guest, this allows one-directional communication so you can defer rendering to the client and not suffer from the latency. But I may be mixing things up. > >> >> No, qxl is our paravirt vga, we should improve it instead of spawning >> new ones (which will be horrible in the eyes of the next person to look >> at them). You should also be getting the drm driver for free. > > Actually, Gerd et al have expressed interest in moving to a virtio-based > device model for Spice in the past. > > I think done correctly, it could help bring graphics to other platforms > like S390 where PCI doesn't exist and will never exist. I thought the plan was to render into a virtual card punch, then flip through the cards at 60 fps? Virtio makes sense for qxl, but for now we have the original pci model which I don't see a reason why it can't work for ppc. -- error compiling committee.c: too many arguments to function