[Qemu-devel] QEMU 0.8.1 and vnc

[Qemu-devel] QEMU 0.8.1 and vnc

[Ben Taylor]

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


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)

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)

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

Host is solaris 9/sparc and solaris 11/x86, viewer is tightvnc V 1.2.8 on solaris 11/x86.

[-- Attachment #2: Screenshot-Vncviewer.png --]
[-- Type: image/png, Size: 81379 bytes --]

[Qemu-devel] Re: QEMU 0.8.1 and vnc

[Anthony Liguori]

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.

Regards,

Anthony Liguori

> Host is solaris 9/sparc and solaris 11/x86, viewer is tightvnc V 1.2.8 on solaris 11/x86.
>
> ------------------------------------------------------------------------
>

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

[Troy Benjegerdes]

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

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

[andrzej zaborowski]

Hi,

On 12/05/06, 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).
> >
> > >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 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)
>
>
>
> _______________________________________________
> 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

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

[Ben Taylor]

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


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


> 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

[-- Attachment #2: Solaris-Sparc-Qemu-monitor.png --]
[-- Type: image/png, Size: 13713 bytes --]

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

[Anthony Liguori]

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
>   

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

[Chris Wilson]

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 <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

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

[Paul Brook]

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

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

[Anthony Liguori]

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
>   

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

[Jamie Lokier]

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