qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Date: Mon, 30 Jul 2012 14:58:15 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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?

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.

http://spice-space.org/page/DRM

-- 
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]