Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc

[Anthony Liguori <anthony@codemonkey.ws>]

Ben Taylor wrote:
> ---- Troy Benjegerdes <hozer@hozed.org> wrote: 
>   
>> On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote:
>>     
>>> Ben Taylor wrote:
>>>       
>>>> I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature
>>>>
>>>> 1) Sparc based system comes up in distored colors (foreground of a Damn 
>>>> Small linux
>>>> iso comes up in yellow, instead of white)
>>>>  
>>>>         
>>> This is a know problem.  qemu doesn't give any indication that the guest 
>>> is storing pixels in big endian mode.  A proper fix is on my TODO list.
>>>
>>>       
>>>> 2) When it bounces from the initial syslinux text to the grahpical screen, 
>>>> it leaves the text
>>>> in the top left corner not cleared. (to the boot: at the bottom)
>>>>  
>>>>         
>>> Yeah, I've noticed something similar myself.  It's on the TODO list (see 
>>> vnc.c).
>>>
>>>       
>>>>  
>>>>         
>>> TightVNC doesn't support the desktop resize encoding.  Try RealVNC.
>>>       
>> I am running the current CVS code and seeing endian color problems with
>> a x86 machine running qemu and a PPC linux machine running
>> xrealvncviewer.
>>
>> This is the debian xvncviewer package version 3.3.7-7. 
>>
>> Also, how does one get to the qemu console with the vnc?
>>     
>
> I usually start qemu with "-S -monitor stdio -vnc 0" which gives me a (qemu) prompt
> on  the starting terminal, then I start vnc and then type "cont" in the monitor window
> (starting terminal)
>
> However, another buglet WRT to vnc that I've found is this.  When I do the following
> from a Solaris/Sparc host, and display on a Solaris/X86 client using vncviewer,
> I get the following corruption (see attachment Solaris-sparc-qemu-monitor.png)
>   

This is a problem with the VNC protocol itself.  The format of the 
protocol messages depend on the current pixel format which requires that 
the server and client are in sync with what they think the pixel format is.

A problem arises when the client sends a SetPixelFormat message.  There 
is no "ack" message from the server so the client has to assume that as 
soon as it sends out the message, the server is now using the new pixel 
format.  RealVNC uses totally synchronous IO routines so in practice, 
the window for this race condition is small for them.  It definitely can 
occur though and I've reproduced it with a normal VNC server.

Since the QEmu VNC code is completely asynchronous, we have a much 
larger window where this race can occur.  The easiest thing to do is 
avoid the race all together and not have your client use SetPixelFormat 
frequently.  This is really only an issue with the RealVNC client.  You 
can avoid this by doing:

vncviewer AutoSelect=0 FullColor=1...

A proper fix requires extending the VNC protocol.  Of course, this 
requires that the client support the extension.

Regards,

Anthony Liguori

>   
>> The vnc server also seems to occasionally send invalid vnc packets, and
>> the screen resize does not seem to work. Included is a log of starting up
>> and exiting because a bad message.. The bad message problem occurs with 
>> Chicken of the VNC on MacOS X as well.
>>
>>
>> VNC viewer version 3.3.7 - built Sep 25 2004 21:02:46
>> Copyright (C) 2002-2003 RealVNC Ltd.
>> Copyright (C) 1994-2000 AT&T Laboratories Cambridge.
>> See http://www.realvnc.com for information on VNC.
>> VNC server supports protocol version 3.3 (viewer 3.3)
>> No authentication needed
>> Desktop name "QEMU"
>> Connected to VNC server, using protocol version 3.3
>> VNC server default format:
>>   32 bits per pixel.
>>   Least significant byte first in each pixel.
>>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
>> Using default colormap and visual, TrueColor, depth 24.
>> Got 256 exact BGR233 colours out of 256
>> Using BGR233 pixel format:
>>   8 bits per pixel.
>>   True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6
>> Throughput 20000 kbit/s - changing to Hextile
>> Throughput 20000 kbit/s - changing from 8bit
>> Using viewer's native pixel format:
>>   32 bits per pixel.
>>   Most significant byte first in each pixel.
>>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
>> Rect too large: 69x1 at (705, 577)
>>     
>
> I am definitely seeing this happen with the Solaris/Sparc host and Solaris/X86
> Real vncviewer.
>
> Ben
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>