Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out

[Avi Kivity <avi@redhat.com>]

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