[Qemu-devel] Spice and legacy VGA drivers

[Qemu-devel] Spice and legacy VGA drivers

[Anthony Liguori]

How does this work?

Does Spice only work with QXL or can it also work with Cirrus and 
std-vga?  Does it degrade into basically a framebuffer based protocol?  
How does it encode the bitmap data in this mode?

Regards,

Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 09:25:00 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> How does this work?
> 
> Does Spice only work with QXL or can it also work with Cirrus and 
> std-vga?  Does it degrade into basically a framebuffer based
> protocol? How does it encode the bitmap data in this mode?

It work with std-vga
It send bitmaps using the dirty bit from kvm/qemu

> 
> Regards,
> 
> Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Anthony Liguori]

Izik Eidus wrote:
> On Sat, 12 Dec 2009 09:25:00 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> How does this work?
>>
>> Does Spice only work with QXL or can it also work with Cirrus and 
>> std-vga?  Does it degrade into basically a framebuffer based
>> protocol? How does it encode the bitmap data in this mode?
>>     
>
> It work with std-vga
> It send bitmaps using the dirty bit from kvm/qemu
>   

How does it compress the bitmaps?

Regards,

Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 11:19:19 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > On Sat, 12 Dec 2009 09:25:00 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> >   
> >> How does this work?
> >>
> >> Does Spice only work with QXL or can it also work with Cirrus and 
> >> std-vga?  Does it degrade into basically a framebuffer based
> >> protocol? How does it encode the bitmap data in this mode?
> >>     
> >
> > It work with std-vga
> > It send bitmaps using the dirty bit from kvm/qemu
> >   
> 
> How does it compress the bitmaps?

What you mean? how can it compress it? or what method?

When there is no driver installed, we use compression that based on
LZ...
How does it compress it?, it just send it to the spice server as
"Draw bitmap" command and the spice server send it to the client.

> 
> Regards,
> 
> Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Anthony Liguori]

Izik Eidus wrote:
> What you mean? how can it compress it? or what method?
>
> When there is no driver installed, we use compression that based on
> LZ...
>   

Okay, that's what I was asking.  I'm curious because during guest 
installation, I assume that even if you're using QXL, you are still 
stuck in VESA mode.

I'm curious if LZ on it's own is significantly different than some of 
the vnc encodings.  Both ZRLE and Tight have some pre-encoding 
techniques that introduce a palette and in the case of Tight, also 
support efficient gradient encoding.  The idea is that you end up with 
much more compressable data this way.

It's the sort of thing I think would be interesting to measure.  I think 
being able to use VNC style encodings could also be interesting for 
Spice in order to improve this "legacy mode" use-case.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 11:35:24 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > What you mean? how can it compress it? or what method?
> >
> > When there is no driver installed, we use compression that based on
> > LZ...
> >   
> 
> Okay, that's what I was asking.  I'm curious because during guest 
> installation, I assume that even if you're using QXL, you are still 
> stuck in VESA mode.


Correct.

> 
> I'm curious if LZ on it's own is significantly different than some of 
> the vnc encodings.  Both ZRLE and Tight have some pre-encoding 
> techniques that introduce a palette and in the case of Tight, also 
> support efficient gradient encoding.  The idea is that you end up
> with much more compressable data this way.
> 
> It's the sort of thing I think would be interesting to measure.  I
> think being able to use VNC style encodings could also be interesting
> for Spice in order to improve this "legacy mode" use-case.


That specific area in spice will be changed very soon due to new
requiments that the offscreens will add.
Windows direct draw allow modifying offscreen (or even primary)
surfaces using a pointer giving to the user, this mean we can`t know
what parts of the surface was changed... (In some modes the primary
screen can be changed without we know about this)

We already thought about few algorithems we might want to add to spice
to better address this "changed without notifications surfaces", But it
is still not in a state I can confirm in what direction we will go in
the end (We still need to test most of the cases to know what fit us
best)

Thanks.

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Anthony Liguori]

Izik Eidus wrote:
> That specific area in spice will be changed very soon due to new
> requiments that the offscreens will add.
> Windows direct draw allow modifying offscreen (or even primary)
> surfaces using a pointer giving to the user, this mean we can`t know
> what parts of the surface was changed... (In some modes the primary
> screen can be changed without we know about this)
>
> We already thought about few algorithems we might want to add to spice
> to better address this "changed without notifications surfaces", But it
> is still not in a state I can confirm in what direction we will go in
> the end (We still need to test most of the cases to know what fit us
> best)
>   

Okay, I'm interested in hearing more about this as it develops.  I think 
good support for legacy modes is an important requirement.

For instance, I very often interact with VMs in text console mode.  In 
cloud deployments, it's pretty common to have minimal appliances that 
don't have a full X session.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 13:28:18 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > That specific area in spice will be changed very soon due to new
> > requiments that the offscreens will add.
> > Windows direct draw allow modifying offscreen (or even primary)
> > surfaces using a pointer giving to the user, this mean we can`t know
> > what parts of the surface was changed... (In some modes the primary
> > screen can be changed without we know about this)
> >
> > We already thought about few algorithems we might want to add to
> > spice to better address this "changed without notifications
> > surfaces", But it is still not in a state I can confirm in what
> > direction we will go in the end (We still need to test most of the
> > cases to know what fit us best)
> >   
> 
> Okay, I'm interested in hearing more about this as it develops.  I
> think good support for legacy modes is an important requirement.
> 
> For instance, I very often interact with VMs in text console mode.
> In cloud deployments, it's pretty common to have minimal appliances
> that don't have a full X session.

Sure, this exactly why we still dont sure what kind of algorithem we
will use... , we are searching for something that wont deprived any
usage (Such as text console mode, or "modified by pointer surface")

Thanks.


> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Dave Airlie]

On Sun, Dec 13, 2009 at 5:28 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Izik Eidus wrote:
>>
>> That specific area in spice will be changed very soon due to new
>> requiments that the offscreens will add.
>> Windows direct draw allow modifying offscreen (or even primary)
>> surfaces using a pointer giving to the user, this mean we can`t know
>> what parts of the surface was changed... (In some modes the primary
>> screen can be changed without we know about this)
>>
>> We already thought about few algorithems we might want to add to spice
>> to better address this "changed without notifications surfaces", But it
>> is still not in a state I can confirm in what direction we will go in
>> the end (We still need to test most of the cases to know what fit us
>> best)
>>
>
> Okay, I'm interested in hearing more about this as it develops.  I think
> good support for legacy modes is an important requirement.
>
> For instance, I very often interact with VMs in text console mode.  In cloud
> deployments, it's pretty common to have minimal appliances that don't have a
> full X session.

We should develop a KMS stack for QXL like VMware have done for SVGA,

This would mean getting a fb console in the guests and you can use fb's
dirty support. Getting out of VGA ASAP is a kernel graphics driver goal going
forward.

Also re:cairo, nearly ever app on my desktop uses it via gtk.
Now how many properitary apps exist that don't is an open
question, but anyone using QT or GTK will be using X render for lots of
drawing right now.

I'm not really sure how VNC works at the non-screen scraping level so I suppose
I should investigate, I've never seen VNC as useful fit for doing 3D rendering,
but I suppose it could be extended.

Dave.