|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc |
Date: | Fri, 12 May 2006 21:30:59 -0500 |
User-agent: | Mail/News 1.5 (X11/20060309) |
Ben Taylor wrote:
---- Troy Benjegerdes <address@hidden> wrote:On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote:Ben Taylor wrote: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.I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature1) Sparc based system comes up in distored colors (foreground of a Damn Small linuxiso comes up in yellow, instead of white)2) When it bounces from the initial syslinux text to the grahpical screen, it leaves the textYeah, I've noticed something similar myself. It's on the TODO list (see vnc.c).in the top left corner not cleared. (to the boot: at the bottom)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 upand 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 address@hidden http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Prev in Thread] | Current Thread | [Next in Thread] |