VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Mark Cave-Ayland]

Hi all,

Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our 
servers, I've noticed that I am seeing block artefacts when connecting 
using VNC to the graphical VGA console of a WinXP guest.

Looking at the VNC output, what I am seeing is that instead of updating 
some parts of the screen which require a redraw, they are just being 
replaced by light grey blocks of around 16x16 pixels. Generally, but not 
always, several of these blocks appear in a row. Moving the mouse over 
the relevant sections of the screen causes them to be redrawn correctly.

I've tried this using both the cirrus and vga drivers, switching between 
16/24/32 bit colour and also different resolutions and unfortunately the 
effect still remains :( Is there anything else I can do to help try and 
debug this? Again this is on an x86_64 Debian Lenny host with a 2.6.32.2 
kernel on Intel.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Re: VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Marcelo Tosatti]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Tue, Jan 05, 2010 at 04:11:26PM +0000, Mark Cave-Ayland wrote:
> Hi all,
>
> Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our  
> servers, I've noticed that I am seeing block artefacts when connecting  
> using VNC to the graphical VGA console of a WinXP guest.
>
> Looking at the VNC output, what I am seeing is that instead of updating  
> some parts of the screen which require a redraw, they are just being  
> replaced by light grey blocks of around 16x16 pixels. Generally, but not  
> always, several of these blocks appear in a row. Moving the mouse over  
> the relevant sections of the screen causes them to be redrawn correctly.
>
> I've tried this using both the cirrus and vga drivers, switching between  
> 16/24/32 bit colour and also different resolutions and unfortunately the  
> effect still remains :( Is there anything else I can do to help try and  
> debug this? Again this is on an x86_64 Debian Lenny host with a 2.6.32.2  
> kernel on Intel.

Mark,

Can you confirm that reverting commit
02c2b87fff97e77a1f6033fb09f53afa267c0c1e fixes the problem? (patch
attached).

Anthony: its reproducible with upstream/tcg.


[-- Attachment #2: qemu-revert-02c2.patch --]
[-- Type: text/plain, Size: 666 bytes --]

diff --git a/vnchextile.h b/vnchextile.h
index 432ed89..c96ede3 100644
--- a/vnchextile.h
+++ b/vnchextile.h
@@ -73,7 +73,7 @@ static void CONCAT(send_hextile_tile_, NAME)(VncState *vs,
 	*last_bg = bg;
     }
 
-    if (n_colors < 3 && (!*has_fg || *last_fg != fg)) {
+    if (!*has_fg || *last_fg != fg) {
 	flags |= 0x04;
 	*has_fg = 1;
 	*last_fg = fg;
@@ -165,6 +165,8 @@ static void CONCAT(send_hextile_tile_, NAME)(VncState *vs,
 	    irow += ds_get_linesize(vs->ds) / sizeof(pixel_t);
 	}
 
+	/* A SubrectsColoured subtile invalidates the foreground color */
+	*has_fg = 0;
 	if (n_data > (w * h * sizeof(pixel_t))) {
 	    n_colors = 4;
 	    flags = 0x01;

Re: VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Mark Cave-Ayland]

Marcelo Tosatti wrote:

> Mark,
> 
> Can you confirm that reverting commit
> 02c2b87fff97e77a1f6033fb09f53afa267c0c1e fixes the problem? (patch
> attached).
> 
> Anthony: its reproducible with upstream/tcg.

Hi Marcelo,

Yes, this solves the problem for me - thanks a lot!

FWIW there is still another race condition in the VNC code somewhere. 
Due to the bad weather in the UK today, I'm working remotely over an SSH 
tunnel which seems to exacerbate the problem. What I see is that when 
scrolling large windows in WinXP quickly, my VNC client disconnects from 
the VGA framebuffer with messages like this:


  CConn:       Throughput 1131 kbit/s - changing to full colour
  CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
Rect too big: 7088x27 at 4123,40960 exceeds 800x600
  main:        Rect too big

  CConn:       Throughput 1093 kbit/s - changing to full colour
  CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
Rect too big: 30224x50704 at 50448,13840 exceeds 720x400
  main:        Rect too big


While I can always reconnect and continue where I left off, it can still 
be quite annoying sometimes.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Re: VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Anthony Liguori]

On 01/06/2010 07:51 AM, Marcelo Tosatti wrote:
> On Tue, Jan 05, 2010 at 04:11:26PM +0000, Mark Cave-Ayland wrote:
>    
>> Hi all,
>>
>> Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
>> servers, I've noticed that I am seeing block artefacts when connecting
>> using VNC to the graphical VGA console of a WinXP guest.
>>
>> Looking at the VNC output, what I am seeing is that instead of updating
>> some parts of the screen which require a redraw, they are just being
>> replaced by light grey blocks of around 16x16 pixels. Generally, but not
>> always, several of these blocks appear in a row. Moving the mouse over
>> the relevant sections of the screen causes them to be redrawn correctly.
>>
>> I've tried this using both the cirrus and vga drivers, switching between
>> 16/24/32 bit colour and also different resolutions and unfortunately the
>> effect still remains :( Is there anything else I can do to help try and
>> debug this? Again this is on an x86_64 Debian Lenny host with a 2.6.32.2
>> kernel on Intel.
>>      
> Mark,
>
> Can you confirm that reverting commit
> 02c2b87fff97e77a1f6033fb09f53afa267c0c1e fixes the problem? (patch
> attached).
>
> Anthony: its reproducible with upstream/tcg.

Which vnc client is this?

Regards,

Anthony Liguori

Re: VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Marcelo Tosatti]

On Wed, Jan 06, 2010 at 11:58:14AM -0600, Anthony Liguori wrote:
> On 01/06/2010 07:51 AM, Marcelo Tosatti wrote:
>> On Tue, Jan 05, 2010 at 04:11:26PM +0000, Mark Cave-Ayland wrote:
>>    
>>> Hi all,
>>>
>>> Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
>>> servers, I've noticed that I am seeing block artefacts when connecting
>>> using VNC to the graphical VGA console of a WinXP guest.
>>>
>>> Looking at the VNC output, what I am seeing is that instead of updating
>>> some parts of the screen which require a redraw, they are just being
>>> replaced by light grey blocks of around 16x16 pixels. Generally, but not
>>> always, several of these blocks appear in a row. Moving the mouse over
>>> the relevant sections of the screen causes them to be redrawn correctly.
>>>
>>> I've tried this using both the cirrus and vga drivers, switching between
>>> 16/24/32 bit colour and also different resolutions and unfortunately the
>>> effect still remains :( Is there anything else I can do to help try and
>>> debug this? Again this is on an x86_64 Debian Lenny host with a 2.6.32.2
>>> kernel on Intel.
>>>      
>> Mark,
>>
>> Can you confirm that reverting commit
>> 02c2b87fff97e77a1f6033fb09f53afa267c0c1e fixes the problem? (patch
>> attached).
>>
>> Anthony: its reproducible with upstream/tcg.
>
> Which vnc client is this?

vncviewer and vinagre.

Re: VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Anthony Liguori]

On 01/06/2010 07:51 AM, Marcelo Tosatti wrote:
> On Tue, Jan 05, 2010 at 04:11:26PM +0000, Mark Cave-Ayland wrote:
>    
>> Hi all,
>>
>> Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
>> servers, I've noticed that I am seeing block artefacts when connecting
>> using VNC to the graphical VGA console of a WinXP guest.
>>
>> Looking at the VNC output, what I am seeing is that instead of updating
>> some parts of the screen which require a redraw, they are just being
>> replaced by light grey blocks of around 16x16 pixels. Generally, but not
>> always, several of these blocks appear in a row. Moving the mouse over
>> the relevant sections of the screen causes them to be redrawn correctly.
>>
>> I've tried this using both the cirrus and vga drivers, switching between
>> 16/24/32 bit colour and also different resolutions and unfortunately the
>> effect still remains :( Is there anything else I can do to help try and
>> debug this? Again this is on an x86_64 Debian Lenny host with a 2.6.32.2
>> kernel on Intel.
>>      
> Mark,
>
> Can you confirm that reverting commit
> 02c2b87fff97e77a1f6033fb09f53afa267c0c1e fixes the problem? (patch
> attached).
>
> Anthony: its reproducible with upstream/tcg.

What about just adding back this bit:

@@ -165,6 +165,8 @@ static void CONCAT(send_hextile_tile_, NAME)(VncState *vs,
  	    irow += ds_get_linesize(vs->ds) / sizeof(pixel_t);
  	}

+	/* A SubrectsColoured subtile invalidates the foreground color */
+	*has_fg = 0;
  	if (n_data>  (w * h * sizeof(pixel_t))) {
  	    n_colors = 4;
  	    flags = 0x01;

I think I can rationalize why that would be needed.

Regards,

Anthony Liguori

Re: VNC framebuffer block artefacts on qemu-kvm-0.12.1.1

[Mark Cave-Ayland]

Anthony Liguori wrote:

> What about just adding back this bit:
> 
> @@ -165,6 +165,8 @@ static void CONCAT(send_hextile_tile_, 
> NAME)(VncState *vs,
>          irow += ds_get_linesize(vs->ds) / sizeof(pixel_t);
>      }
> 
> +    /* A SubrectsColoured subtile invalidates the foreground color */
> +    *has_fg = 0;
>      if (n_data>  (w * h * sizeof(pixel_t))) {
>          n_colors = 4;
>          flags = 0x01;
> 
> I think I can rationalize why that would be needed.

Hi Anthony,

I've done a rebuild with just the above part of the patch applied, and I 
can confirm that indeed it resolves the problem on my WinXP guest here.


Many thanks,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs