Ben Taylor wrote:
---- Troy Benjegerdes <[EMAIL PROTECTED]> 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

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) 
on  the starting terminal, then I start vnc and then type "cont" in the monitor 
(starting terminal)

However, another buglet WRT to vnc that I've found is this.  When I do the 
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.


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 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.




Qemu-devel mailing list

Qemu-devel mailing list

Reply via email to