On 07/30/2012 04:18 PM, Anthony Liguori wrote: > Avi Kivity <a...@redhat.com> 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