Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Anthony Liguori wrote: > Exactly. If you have a good network connection, you'll tend to get > lucky. The conditions for this race to happen are 1) a server receives > a SetPixelFormat with a different BPP 2) the server has already sent > data on the wire in the previous BPP but the client did not receive it > before sending the SetPixelFormat message. > > Changing the BPP is rare. RealVNC does it because it attempts to be > smart about reducing bandwidth (it drops down to 8bpp and then goes back > up to 32bpp if the transfer rate is fast enough). > > The best way to avoid this behavior is to use AutoSelect=0 FullColor=1 > on the vncviewer command line. How do other VNC servers avoid this problem, or do they all have it? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Paul Brook wrote: On Saturday 13 May 2006 16:15, Chris Wilson wrote: Hi Anthony, On Fri, 12 May 2006, Anthony Liguori wrote: 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. Please forgive my ignorance, but why is there a race condition here? You have exactly one socket open between client and server. It's a TCP socket so out-of-order delivery or missing messages is impossible. Yes, but it's a bidirectional connection. The client doesn't know if the packet it just received was send before or after the server received the SetPixelFormat message. Exactly. If you have a good network connection, you'll tend to get lucky. The conditions for this race to happen are 1) a server receives a SetPixelFormat with a different BPP 2) the server has already sent data on the wire in the previous BPP but the client did not receive it before sending the SetPixelFormat message. Changing the BPP is rare. RealVNC does it because it attempts to be smart about reducing bandwidth (it drops down to 8bpp and then goes back up to 32bpp if the transfer rate is fast enough). The best way to avoid this behavior is to use AutoSelect=0 FullColor=1 on the vncviewer command line. Regards, Anthony Liguori Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
On Saturday 13 May 2006 16:15, Chris Wilson wrote: > Hi Anthony, > > On Fri, 12 May 2006, Anthony Liguori wrote: > > 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. > > Please forgive my ignorance, but why is there a race condition here? You > have exactly one socket open between client and server. It's a TCP socket > so out-of-order delivery or missing messages is impossible. Yes, but it's a bidirectional connection. The client doesn't know if the packet it just received was send before or after the server received the SetPixelFormat message. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Hi Anthony, On Fri, 12 May 2006, Anthony Liguori wrote: 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. Please forgive my ignorance, but why is there a race condition here? You have exactly one socket open between client and server. It's a TCP socket so out-of-order delivery or missing messages is impossible. Presumably the VNC protocol does not allow you to send a message in the middle of another one. So at any given time, the process/thread that controls the socket should know exactly what pixel format it's expected to send messages, at the time of transmission, based on the last SetPixelFormat that has been dispatched. If you have multiple threads encoding messages at the same, then I can see how one thread could start encoding a block for a particular endianness, and meanwhile another thread is sending a SetPixelFormat message which would change the endianness. If that were the case, then you could have the block sender detect that SetPixelFormat had been sent, at the end of its encoding process, and start encoding again using the new pixel format. But surely the virtual graphics card would be the source of both types of messages, and surely its code runs only in a single thread? Anything else would seem bizarre to me. Thanks in advance for enlightenment. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson < at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
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 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 2 kbit/s - changing to Hextile Throughput 2 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
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 > 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) > 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 2 kbit/s - changing to Hextile > Throughput 2 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 Solaris-Sparc-Qemu-monitor.png Description: PNG image ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Hi, On 12/05/06, 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). > > >3) screen autoresize is not working. 2 examples with DSL. > >a) initial screen is 80x25, but qemu comes up in 80x24 and stays there > >and I can't see "boot:" prompt at the bottom. > >b) when it goes into graphical mode, it's not resizing so I'm missing > >some portion of > > the screen > > > > 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? Currently you need to either apply this patch: http://www.zabor.org/balrog/qemu-curses-etc.patch which will add switching consoles the SDL way (ctrl-alt-number) or run qemu with "-monitor stdio", and the monitor will then accept commands from the terminal in which qemu was started. 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 2 kbit/s - changing to Hextile Throughput 2 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) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Greetings, Andrew -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
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). > > >3) screen autoresize is not working. 2 examples with DSL. > >a) initial screen is 80x25, but qemu comes up in 80x24 and stays there > >and I can't see "boot:" prompt at the bottom. > >b) when it goes into graphical mode, it's not resizing so I'm missing > >some portion of > > the screen > > > > 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? 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 2 kbit/s - changing to Hextile Throughput 2 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) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
