pixel format is out of sync, after refreshing and suddenly changing pixel format

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

pixel format is out of sync, after refreshing and suddenly changing pixel format

Anon Sricharoenchai-2
Hi,

I'm not sure to call this a bug in vncviewer, or a bug in VNC protocol.

Anyhow, this bug apply to realvnc 4.0 to 4.1.1.  The bug may
demonstrate the flaw in VNC protocol, which don't have any mechanism
to ensure the synchronization of the pixel format between client and
server.

Let's see how to reproduce this bug first, and then see how pixel
format is out of sync.
(To view this bug in a clear formatted text, visit
http://opensource.wikia.com/wiki/Bugs:realvnc4/pixel_format_is_unpredictable_after_refreshing_and_suddenly_changing_pixel_format
)

== How to reproduce ==
Run the following command in some terminal, "terminal1", in this example,

   terminal1 $ Xvnc :1 -nolisten tcp -auth /dev/null -localhost
-SecurityTypes=None -geometry 800x600 -depth 24 &
   terminal1 $ DISPLAY=:1 xterm -e perl -e '$|=1; for(;;){print".";
select(undef,undef,undef,0.001); }' &

Then open another terminal, "terminal2", run vncviewer,

   terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1 -FullColor

   VNC Viewer Free Edition 4.1.1 for X - built Jan  6 2007 00:46:26
   Copyright (C) 2002-2005 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Fri Dec  7 20:11:20 2007
    CConn:       connected to host localhost port 5901

   Fri Dec  7 20:11:21 2007
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
    CConn:       Using ZRLE encoding

Switch back to "terminal1", suspend the Xvnc,

   terminal1 $ killall -TSTP Xvnc

Then switch to vncviewer x11 window, refresh screen, and change colour level,

   vncviewer x11: press F8 --> select "Refresh screen"
   vncviewer x11: press F8 --> select "Options..." --> select "Very
low (8 colours)" in "Encoding and Colour Level:" --> click "Ok"

Switch to "terminal1", resume Xvnc,

   terminal1 $ killall -CONT Xvnc

vncviewer will then fail like this,

   terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1 -FullColor
   <--cut-->
   ...
   <--cut-->
    CConn:       Using ZRLE encoding

   Fri Dec  7 20:11:45 2007
    CConn:       Using pixel format depth 3 (8bpp) rgb111
   vncviewer: ../rfb/zrleDecode.h:196: void rfb::zrleDecode8(const
rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*,
rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
   Aborted



== Cause ==
This is because the client and server fail to synchronize the pixel
format, which is depicted as follow,

                             server send FramebufferUpdate0
                             server is suspended
   client receive FramebufferUpdate0
   client send FramebufferUpdateRequest1:incremental=true

   user request refresh screen
   client send FramebufferUpdateRequest2:incremental=false
   user change colour level

                             server is resumed
                             server receive
FramebufferUpdateRequest1:incremental=true
                             server send FramebufferUpdate1
   client receive FramebufferUpdate1
   client change its internal pixel format to new pixel format
   client send SetPixelFormat
   client send FramebufferUpdateRequest3:incremental=false
              (non-incremental since pixel format changed)
   client is now expecting new pixel format from server
                             server receive
FramebufferUpdateRequest2:incremental=false
                             server send FramebufferUpdate2 with old
pixel format
   client receive FramebufferUpdate2 with old pixel format
   client interprete FramebufferUpdate2 as new pixel format
   client mis-interprete pixel format, and then fail

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

RE: pixel format is out of sync, after refreshing and suddenly changing pixel format

James Weatherall
Hi Anon,

This is a know limitation of the Refresh Screen option in VNC Free Edition &
VNC Free Edition-based software, which isn't "safe" to use if the VNC Viewer
might be changing pixel format at a later point.  You shouldn't need to use
Refresh Screen, in general.

Cheers,

--
Wez @ RealVNC Ltd
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Anon Sricharoenchai
> Sent: 12 December 2007 12:25
> To: [hidden email];
> [hidden email]; [hidden email]
> Subject: pixel format is out of sync, after refreshing and
> suddenly changing pixel format
>
> Hi,
>
> I'm not sure to call this a bug in vncviewer, or a bug in VNC
> protocol.
>
> Anyhow, this bug apply to realvnc 4.0 to 4.1.1.  The bug may
> demonstrate the flaw in VNC protocol, which don't have any
> mechanism to ensure the synchronization of the pixel format
> between client and server.
>
> Let's see how to reproduce this bug first, and then see how
> pixel format is out of sync.
> (To view this bug in a clear formatted text, visit
> http://opensource.wikia.com/wiki/Bugs:realvnc4/pixel_format_is
> _unpredictable_after_refreshing_and_suddenly_changing_pixel_format
> )
>
> == How to reproduce ==
> Run the following command in some terminal, "terminal1", in
> this example,
>
>    terminal1 $ Xvnc :1 -nolisten tcp -auth /dev/null
> -localhost -SecurityTypes=None -geometry 800x600 -depth 24 &
>    terminal1 $ DISPLAY=:1 xterm -e perl -e '$|=1;
> for(;;){print"."; select(undef,undef,undef,0.001); }' &
>
> Then open another terminal, "terminal2", run vncviewer,
>
>    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1
> -FullColor
>
>    VNC Viewer Free Edition 4.1.1 for X - built Jan  6 2007 00:46:26
>    Copyright (C) 2002-2005 RealVNC Ltd.
>    See http://www.realvnc.com for information on VNC.
>
>    Fri Dec  7 20:11:20 2007
>     CConn:       connected to host localhost port 5901
>
>    Fri Dec  7 20:11:21 2007
>     CConnection: Server supports RFB protocol version 3.8
>     CConnection: Using RFB protocol version 3.8
>     TXImage:     Using default colormap and visual,
> TrueColor, depth 24.
>     CConn:       Using pixel format depth 24 (32bpp)
> little-endian rgb888
>     CConn:       Using ZRLE encoding
>
> Switch back to "terminal1", suspend the Xvnc,
>
>    terminal1 $ killall -TSTP Xvnc
>
> Then switch to vncviewer x11 window, refresh screen, and
> change colour level,
>
>    vncviewer x11: press F8 --> select "Refresh screen"
>    vncviewer x11: press F8 --> select "Options..." --> select
> "Very low (8 colours)" in "Encoding and Colour Level:" --> click "Ok"
>
> Switch to "terminal1", resume Xvnc,
>
>    terminal1 $ killall -CONT Xvnc
>
> vncviewer will then fail like this,
>
>    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1
> -FullColor
>    <--cut-->
>    ...
>    <--cut-->
>     CConn:       Using ZRLE encoding
>
>    Fri Dec  7 20:11:45 2007
>     CConn:       Using pixel format depth 3 (8bpp) rgb111
>    vncviewer: ../rfb/zrleDecode.h:196: void
> rfb::zrleDecode8(const rfb::Rect&, rdr::InStream*,
> rdr::ZlibInStream*, rdr::U8*,
> rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
>    Aborted
>
>
>
> == Cause ==
> This is because the client and server fail to synchronize the
> pixel format, which is depicted as follow,
>
>                              server send FramebufferUpdate0
>                              server is suspended
>    client receive FramebufferUpdate0
>    client send FramebufferUpdateRequest1:incremental=true
>
>    user request refresh screen
>    client send FramebufferUpdateRequest2:incremental=false
>    user change colour level
>
>                              server is resumed
>                              server receive
> FramebufferUpdateRequest1:incremental=true
>                              server send FramebufferUpdate1
>    client receive FramebufferUpdate1
>    client change its internal pixel format to new pixel format
>    client send SetPixelFormat
>    client send FramebufferUpdateRequest3:incremental=false
>               (non-incremental since pixel format changed)
>    client is now expecting new pixel format from server
>                              server receive
> FramebufferUpdateRequest2:incremental=false
>                              server send FramebufferUpdate2
> with old pixel format
>    client receive FramebufferUpdate2 with old pixel format
>    client interprete FramebufferUpdate2 as new pixel format
>    client mis-interprete pixel format, and then fail
> _______________________________________________
> VNC-List mailing list
> [hidden email]
> To remove yourself from the list visit:
> http://www.realvnc.com/mailman/listinfo/vnc-list
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

astrand (Bugzilla)
In reply to this post by Anon Sricharoenchai-2

At a glance, this looks like the same problem I had a few years ago. See
the thread http://article.gmane.org/gmane.network.vnc.user/18430. (Click
on the subject).


Best regards,
Peter Åstrand

On Wed, 12 Dec 2007, Anon Sricharoenchai wrote:

> Hi,
>
> I'm not sure to call this a bug in vncviewer, or a bug in VNC protocol.
>
> Anyhow, this bug apply to realvnc 4.0 to 4.1.1.  The bug may
> demonstrate the flaw in VNC protocol, which don't have any mechanism
> to ensure the synchronization of the pixel format between client and
> server.
>
> Let's see how to reproduce this bug first, and then see how pixel
> format is out of sync.
> (To view this bug in a clear formatted text, visit
> http://opensource.wikia.com/wiki/Bugs:realvnc4/pixel_format_is_unpredictable_after_refreshing_and_suddenly_changing_pixel_format
> )
>
> == How to reproduce ==
> Run the following command in some terminal, "terminal1", in this example,
>
>    terminal1 $ Xvnc :1 -nolisten tcp -auth /dev/null -localhost
> -SecurityTypes=None -geometry 800x600 -depth 24 &
>    terminal1 $ DISPLAY=:1 xterm -e perl -e '$|=1; for(;;){print".";
> select(undef,undef,undef,0.001); }' &
>
> Then open another terminal, "terminal2", run vncviewer,
>
>    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1 -FullColor
>
>    VNC Viewer Free Edition 4.1.1 for X - built Jan  6 2007 00:46:26
>    Copyright (C) 2002-2005 RealVNC Ltd.
>    See http://www.realvnc.com for information on VNC.
>
>    Fri Dec  7 20:11:20 2007
>     CConn:       connected to host localhost port 5901
>
>    Fri Dec  7 20:11:21 2007
>     CConnection: Server supports RFB protocol version 3.8
>     CConnection: Using RFB protocol version 3.8
>     TXImage:     Using default colormap and visual, TrueColor, depth 24.
>     CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
>     CConn:       Using ZRLE encoding
>
> Switch back to "terminal1", suspend the Xvnc,
>
>    terminal1 $ killall -TSTP Xvnc
>
> Then switch to vncviewer x11 window, refresh screen, and change colour level,
>
>    vncviewer x11: press F8 --> select "Refresh screen"
>    vncviewer x11: press F8 --> select "Options..." --> select "Very
> low (8 colours)" in "Encoding and Colour Level:" --> click "Ok"
>
> Switch to "terminal1", resume Xvnc,
>
>    terminal1 $ killall -CONT Xvnc
>
> vncviewer will then fail like this,
>
>    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1 -FullColor
>    <--cut-->
>    ...
>    <--cut-->
>     CConn:       Using ZRLE encoding
>
>    Fri Dec  7 20:11:45 2007
>     CConn:       Using pixel format depth 3 (8bpp) rgb111
>    vncviewer: ../rfb/zrleDecode.h:196: void rfb::zrleDecode8(const
> rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*,
> rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
>    Aborted
>
>
>
> == Cause ==
> This is because the client and server fail to synchronize the pixel
> format, which is depicted as follow,
>
>                              server send FramebufferUpdate0
>                              server is suspended
>    client receive FramebufferUpdate0
>    client send FramebufferUpdateRequest1:incremental=true
>
>    user request refresh screen
>    client send FramebufferUpdateRequest2:incremental=false
>    user change colour level
>
>                              server is resumed
>                              server receive
> FramebufferUpdateRequest1:incremental=true
>                              server send FramebufferUpdate1
>    client receive FramebufferUpdate1
>    client change its internal pixel format to new pixel format
>    client send SetPixelFormat
>    client send FramebufferUpdateRequest3:incremental=false
>               (non-incremental since pixel format changed)
>    client is now expecting new pixel format from server
>                              server receive
> FramebufferUpdateRequest2:incremental=false
>                              server send FramebufferUpdate2 with old
> pixel format
>    client receive FramebufferUpdate2 with old pixel format
>    client interprete FramebufferUpdate2 as new pixel format
>    client mis-interprete pixel format, and then fail
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> VNC-Tight-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
>
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

Anon Sricharoenchai-2
In reply to this post by James Weatherall
This problem doesn't exist in VNC non-free edition?

On 12/12/07, James Weatherall <[hidden email]> wrote:

> Hi Anon,
>
> This is a know limitation of the Refresh Screen option in VNC Free Edition &
> VNC Free Edition-based software, which isn't "safe" to use if the VNC Viewer
> might be changing pixel format at a later point.  You shouldn't need to use
> Refresh Screen, in general.
>
> Cheers,
>
> --
> Wez @ RealVNC Ltd
>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Anon Sricharoenchai
> > Sent: 12 December 2007 12:25
> > To: [hidden email];
> > [hidden email]; [hidden email]
> > Subject: pixel format is out of sync, after refreshing and
> > suddenly changing pixel format
> >
> > Hi,
> >
> > I'm not sure to call this a bug in vncviewer, or a bug in VNC
> > protocol.
> >
> > Anyhow, this bug apply to realvnc 4.0 to 4.1.1.  The bug may
> > demonstrate the flaw in VNC protocol, which don't have any
> > mechanism to ensure the synchronization of the pixel format
> > between client and server.
> >
> > Let's see how to reproduce this bug first, and then see how
> > pixel format is out of sync.
> > (To view this bug in a clear formatted text, visit
> > http://opensource.wikia.com/wiki/Bugs:realvnc4/pixel_format_is
> > _unpredictable_after_refreshing_and_suddenly_changing_pixel_format
> > )
> >
> > == How to reproduce ==
> > Run the following command in some terminal, "terminal1", in
> > this example,
> >
> >    terminal1 $ Xvnc :1 -nolisten tcp -auth /dev/null
> > -localhost -SecurityTypes=None -geometry 800x600 -depth 24 &
> >    terminal1 $ DISPLAY=:1 xterm -e perl -e '$|=1;
> > for(;;){print"."; select(undef,undef,undef,0.001); }' &
> >
> > Then open another terminal, "terminal2", run vncviewer,
> >
> >    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1
> > -FullColor
> >
> >    VNC Viewer Free Edition 4.1.1 for X - built Jan  6 2007 00:46:26
> >    Copyright (C) 2002-2005 RealVNC Ltd.
> >    See http://www.realvnc.com for information on VNC.
> >
> >    Fri Dec  7 20:11:20 2007
> >     CConn:       connected to host localhost port 5901
> >
> >    Fri Dec  7 20:11:21 2007
> >     CConnection: Server supports RFB protocol version 3.8
> >     CConnection: Using RFB protocol version 3.8
> >     TXImage:     Using default colormap and visual,
> > TrueColor, depth 24.
> >     CConn:       Using pixel format depth 24 (32bpp)
> > little-endian rgb888
> >     CConn:       Using ZRLE encoding
> >
> > Switch back to "terminal1", suspend the Xvnc,
> >
> >    terminal1 $ killall -TSTP Xvnc
> >
> > Then switch to vncviewer x11 window, refresh screen, and
> > change colour level,
> >
> >    vncviewer x11: press F8 --> select "Refresh screen"
> >    vncviewer x11: press F8 --> select "Options..." --> select
> > "Very low (8 colours)" in "Encoding and Colour Level:" --> click "Ok"
> >
> > Switch to "terminal1", resume Xvnc,
> >
> >    terminal1 $ killall -CONT Xvnc
> >
> > vncviewer will then fail like this,
> >
> >    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1
> > -FullColor
> >    <--cut-->
> >    ...
> >    <--cut-->
> >     CConn:       Using ZRLE encoding
> >
> >    Fri Dec  7 20:11:45 2007
> >     CConn:       Using pixel format depth 3 (8bpp) rgb111
> >    vncviewer: ../rfb/zrleDecode.h:196: void
> > rfb::zrleDecode8(const rfb::Rect&, rdr::InStream*,
> > rdr::ZlibInStream*, rdr::U8*,
> > rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
> >    Aborted
> >
> >
> >
> > == Cause ==
> > This is because the client and server fail to synchronize the
> > pixel format, which is depicted as follow,
> >
> >                              server send FramebufferUpdate0
> >                              server is suspended
> >    client receive FramebufferUpdate0
> >    client send FramebufferUpdateRequest1:incremental=true
> >
> >    user request refresh screen
> >    client send FramebufferUpdateRequest2:incremental=false
> >    user change colour level
> >
> >                              server is resumed
> >                              server receive
> > FramebufferUpdateRequest1:incremental=true
> >                              server send FramebufferUpdate1
> >    client receive FramebufferUpdate1
> >    client change its internal pixel format to new pixel format
> >    client send SetPixelFormat
> >    client send FramebufferUpdateRequest3:incremental=false
> >               (non-incremental since pixel format changed)
> >    client is now expecting new pixel format from server
> >                              server receive
> > FramebufferUpdateRequest2:incremental=false
> >                              server send FramebufferUpdate2
> > with old pixel format
> >    client receive FramebufferUpdate2 with old pixel format
> >    client interprete FramebufferUpdate2 as new pixel format
> >    client mis-interprete pixel format, and then fail
> > _______________________________________________
> > VNC-List mailing list
> > [hidden email]
> > To remove yourself from the list visit:
> > http://www.realvnc.com/mailman/listinfo/vnc-list
> >
>
>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

Peter Rosin
In reply to this post by James Weatherall
On Wed, Dec 12, 2007 at 01:50:38PM -0000, James Weatherall wrote:
> Hi Anon,
>
> This is a know limitation of the Refresh Screen option in VNC Free Edition &
> VNC Free Edition-based software, which isn't "safe" to use if the VNC Viewer
> might be changing pixel format at a later point.

Nice to see it confirmed, I have been thinking about this for a while
but never got around to formulating it in an email. Also, you seem to
hint that this isn't a problem in the closed sourced versions, can you
enlighten us as to how the problem was resolved, if it has indeed been
resolved?

>                                                   You shouldn't need to use
> Refresh Screen, in general.

Well, that puts limitations on the client implementation. Just as an
example, imagine a client that draws in a framebuffer and that the
user changes screen resolution (or that some other application
"borrows" the framebuffer). The client has only one thing to do when
it wants to refill the framebuffer, if it is not allowed to send a
full refresh request: keep a private copy. That isn't too nice, given
this is a thin client protocol. Oh, right, the client can wait for
the next update to be issued as well and then send a full update
request, but that can be a loooong wait. Not too nice either...

When the solution is a simple as introducing a pseudo-encoding that
gets sent (if requested of course) as an empty rect before any rect
with the new pixfmt is sent, why not introduce that?

That would make the protocol more robust, and is easy to implement.
The client has to take care not to have two pixfmt changes on the
wire simultaneously though, but that's not too much of a limitation.

(Other solutions are of course also possible, this is just the first
that came to mind)

Cheers,
Peter

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

RE: pixel format is out of sync, after refreshing and suddenly changing pixel format

James Weatherall
In reply to this post by astrand (Bugzilla)
Hi Peter,

Not quite.  The problem you described didn't involve Refresh Screen.  In the
absence of Refresh Screen, the scheme used by VNC Free Edition & software
based upon it works correctly.

Regards,

--
Wez @ RealVNC Ltd
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Peter Astrand
> Sent: 12 December 2007 18:17
> To: Anon Sricharoenchai
> Cc: [hidden email]; [hidden email]
> Subject: Re: pixel format is out of sync, after refreshing
> and suddenly changing pixel format
>
> At a glance, this looks like the same problem I had a few
> years ago. See the thread
> http://article.gmane.org/gmane.network.vnc.user/18430. (Click
> on the subject).
>
>
> Best regards,
> Peter Cstrand
>
> On Wed, 12 Dec 2007, Anon Sricharoenchai wrote:
>
> > Hi,
> >
> > I'm not sure to call this a bug in vncviewer, or a bug in
> VNC protocol.
> >
> > Anyhow, this bug apply to realvnc 4.0 to 4.1.1.  The bug may
> > demonstrate the flaw in VNC protocol, which don't have any
> mechanism
> > to ensure the synchronization of the pixel format between
> client and
> > server.
> >
> > Let's see how to reproduce this bug first, and then see how pixel
> > format is out of sync.
> > (To view this bug in a clear formatted text, visit
> >
> http://opensource.wikia.com/wiki/Bugs:realvnc4/pixel_format_is
> _unpredictable_
> after_refreshing_and_suddenly_changing_pixel_format
> > )
> >
> > == How to reproduce ==
> > Run the following command in some terminal, "terminal1", in this
> > example,
> >
> >    terminal1 $ Xvnc :1 -nolisten tcp -auth /dev/null -localhost
> > -SecurityTypes=None -geometry 800x600 -depth 24 &
> >    terminal1 $ DISPLAY=:1 xterm -e perl -e '$|=1; for(;;){print".";
> > select(undef,undef,undef,0.001); }' &
> >
> > Then open another terminal, "terminal2", run vncviewer,
> >
> >    terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1
> > -FullColor
> >
> >    VNC Viewer Free Edition 4.1.1 for X - built Jan  6 2007 00:46:26
> >    Copyright (C) 2002-2005 RealVNC Ltd.
> >    See http://www.realvnc.com for information on VNC.
> >
> >    Fri Dec  7 20:11:20 2007
> >     CConn:       connected to host localhost port 5901
> >
> >    Fri Dec  7 20:11:21 2007
> >     CConnection: Server supports RFB protocol version 3.8
> >     CConnection: Using RFB protocol version 3.8
> >     TXImage:     Using default colormap and visual,
> TrueColor, depth 24.
> >     CConn:       Using pixel format depth 24 (32bpp)
> little-endian rgb888
> >     CConn:       Using ZRLE encoding
> >
> > Switch back to "terminal1", suspend the Xvnc,
> >
> >    terminal1 $ killall -TSTP Xvnc
> >
> > Then switch to vncviewer x11 window, refresh screen, and
> change colour
> level,
> >
> >    vncviewer x11: press F8 --> select "Refresh screen"
> >    vncviewer x11: press F8 --> select "Options..." --> select "Very
> > low (8 colours)" in "Encoding and Colour Level:" --> click "Ok"
> >
> > Switch to "terminal1", resume Xvnc,
> >
> >    terminal1 $ killall -CONT Xvnc
> >
> > vncviewer will then fail like this,
> >
> >    terminal2 $ vncviewer :1 -shared -AutoSelect=0
> -ViewOnly=1 -FullColor
> >    <--cut-->
> >    ...
> >    <--cut-->
> >     CConn:       Using ZRLE encoding
> >
> >    Fri Dec  7 20:11:45 2007
> >     CConn:       Using pixel format depth 3 (8bpp) rgb111
> >    vncviewer: ../rfb/zrleDecode.h:196: void rfb::zrleDecode8(const
> > rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*,
> > rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
> >    Aborted
> >
> >
> >
> > == Cause ==
> > This is because the client and server fail to synchronize the pixel
> > format, which is depicted as follow,
> >
> >                              server send FramebufferUpdate0
> >                              server is suspended
> >    client receive FramebufferUpdate0
> >    client send FramebufferUpdateRequest1:incremental=true
> >
> >    user request refresh screen
> >    client send FramebufferUpdateRequest2:incremental=false
> >    user change colour level
> >
> >                              server is resumed
> >                              server receive
> > FramebufferUpdateRequest1:incremental=true
> >                              server send FramebufferUpdate1
> >    client receive FramebufferUpdate1
> >    client change its internal pixel format to new pixel format
> >    client send SetPixelFormat
> >    client send FramebufferUpdateRequest3:incremental=false
> >               (non-incremental since pixel format changed)
> >    client is now expecting new pixel format from server
> >                              server receive
> > FramebufferUpdateRequest2:incremental=false
> >                              server send FramebufferUpdate2
> with old
> > pixel format
> >    client receive FramebufferUpdate2 with old pixel format
> >    client interprete FramebufferUpdate2 as new pixel format
> >    client mis-interprete pixel format, and then fail
> >
> >
> ----------------------------------------------------------------------
> > ---
> > SF.Net email is sponsored by:
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for just about anything
> > Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > VNC-Tight-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
> >
>
> ---
> Peter Cstrand ThinLinc Chief Developer
> Cendio AB http://www.cendio.se
> Wallenbergs gata 4
> 583 30 LinkC6ping Phone: +46-13-21 46 00
> _______________________________________________
> VNC-List mailing list
> [hidden email]
> To remove yourself from the list visit:
> http://www.realvnc.com/mailman/listinfo/vnc-list
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

RE: pixel format is out of sync, after refreshing and suddenly changing pixel format

James Weatherall
In reply to this post by Peter Rosin
Hi Anon & Peter,

The VNC Personal & Enterprise Editions use a new scheme that does not have
this limitation.

You won't hit problems with the VNC Free Edition system unless you send
multiple outstanding update requests (as is the case when using Refresh
Screen), *and* you change the on-the-wire pixel format *after* having done
that.

Cheers,

--
Wez @ RealVNC Ltd


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Peter Rosin
> Sent: 13 December 2007 08:43
> To: James Weatherall
> Cc: 'Anon Sricharoenchai'; [hidden email];
> [hidden email]
> Subject: Re: pixel format is out of sync, after refreshing
> and suddenly changing pixel format
>
> On Wed, Dec 12, 2007 at 01:50:38PM -0000, James Weatherall wrote:
> > Hi Anon,
> >
> > This is a know limitation of the Refresh Screen option in VNC Free
> > Edition & VNC Free Edition-based software, which isn't
> "safe" to use
> > if the VNC Viewer might be changing pixel format at a later point.
>
> Nice to see it confirmed, I have been thinking about this for
> a while but never got around to formulating it in an email.
> Also, you seem to hint that this isn't a problem in the
> closed sourced versions, can you enlighten us as to how the
> problem was resolved, if it has indeed been resolved?
>
> >                                                   You
> shouldn't need
> > to use Refresh Screen, in general.
>
> Well, that puts limitations on the client implementation.
> Just as an example, imagine a client that draws in a
> framebuffer and that the user changes screen resolution (or
> that some other application "borrows" the framebuffer). The
> client has only one thing to do when it wants to refill the
> framebuffer, if it is not allowed to send a full refresh
> request: keep a private copy. That isn't too nice, given this
> is a thin client protocol. Oh, right, the client can wait for
> the next update to be issued as well and then send a full
> update request, but that can be a loooong wait. Not too nice either...
>
> When the solution is a simple as introducing a
> pseudo-encoding that gets sent (if requested of course) as an
> empty rect before any rect with the new pixfmt is sent, why
> not introduce that?
>
> That would make the protocol more robust, and is easy to implement.
> The client has to take care not to have two pixfmt changes on
> the wire simultaneously though, but that's not too much of a
> limitation.
>
> (Other solutions are of course also possible, this is just
> the first that came to mind)
>
> Cheers,
> Peter
> _______________________________________________
> VNC-List mailing list
> [hidden email]
> To remove yourself from the list visit:
> http://www.realvnc.com/mailman/listinfo/vnc-list
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

Peter Rosin
On Thu, Dec 13, 2007 at 10:09:07AM -0000, James Weatherall wrote:
> Hi Anon & Peter,
>
> The VNC Personal & Enterprise Editions use a new scheme that does not have
> this limitation.
>
> You won't hit problems with the VNC Free Edition system unless you send
> multiple outstanding update requests (as is the case when using Refresh
> Screen), *and* you change the on-the-wire pixel format *after* having done
> that.

Hi Wez,

I'm not talking about the VNC Free Edition system, I'm talking
about the protocol and what clients should do.

The problem is that if a client wants to do a pixfmt change it
has to wait for an outstanding FramebufferUpdateRequest to be
satisfied by a FramebufferUpdate. That's the only way be sure
that the next requested FramebufferUpdate is in the expected
pixfmt, as I'm sure you understand. Hmmm, perhaps not the
only way, see below...

The problem is that you seem to think that this is only a problem
when using the Refresh Screen function in VNC Free Edition, while
my position is that it is a generic protocol problem which puts
unfortunate limitations on clients. So, if the following is true:

1. the client has an outstanding FramebufferUpdateRequest
2. the client has lost its visual framebuffer
3. the client screen depth has changed (likely to cause 2)
4. the client doesn't have a backup copy of the framebuffer
5. the server doesn't have any updates for a long time

then the client will show a blank screen for "an indefinite
period" as the spec puts it. It has to wait for the server before
it can refresh with the new pixfmt. I think it is very valid for
the client to want to change pixfmt and get an update *now*.

Sure, it can send extra non-incremntal FramebufferUpdateRequests
and then try to sort out when it can be sure that no more
FramebufferUpdates are coming down the wire, but that is complex.

The proposed solution in my previous mail is just so much simpler,
and keeps in line with "implementing a client is made as simple
as possible," again from the spec. Just compare to this complex
alternative when you want to change pixfmt and get an update *now*:

1. Send a non-incremental FramebufferUpdateRequest for a small area.
2. Wait for a FramebufferUpdate.
3. If the update does not contain the requested area from 1, goto 7.
4. Send a non-incremental FramebufferUpdateRequest for another
   (non-intersecting) small area.
5. Wait for a FramebufferUpdate.
6. If the update does contain the requested area from 4, goto 8.
7. Wait for a FramebufferUpdate.
8. Send SetPixelFormat.
9. Send full non-incremental FrameBufferUpdateRequest.

Is there a simpler way to work around this without protocol additions
such as new pseudo-encodings?

Cheers,
Peter

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

RE: pixel format is out of sync, after refreshing and suddenly changing pixel format

James Weatherall
Peter,

It is a limitation of the RFB 3.x protocol, which requires that update
requests are required to be matched 1-to-1 by framebuffer updates, although
this isn't strictly required if the pixel format isn't going to change.  It
therefore affects VNC Free Edition & software based upon it.

Cheers,

--
Wez @ RealVNC Ltd
 

> -----Original Message-----
> From: Peter Rosin [mailto:[hidden email]]
> Sent: 13 December 2007 12:16
> To: James Weatherall
> Cc: 'Anon Sricharoenchai'; [hidden email];
> [hidden email]
> Subject: Re: pixel format is out of sync, after refreshing
> and suddenly changing pixel format
>
> On Thu, Dec 13, 2007 at 10:09:07AM -0000, James Weatherall wrote:
> > Hi Anon & Peter,
> >
> > The VNC Personal & Enterprise Editions use a new scheme
> that does not
> > have this limitation.
> >
> > You won't hit problems with the VNC Free Edition system unless you
> > send multiple outstanding update requests (as is the case
> when using
> > Refresh Screen), *and* you change the on-the-wire pixel
> format *after*
> > having done that.
>
> Hi Wez,
>
> I'm not talking about the VNC Free Edition system, I'm
> talking about the protocol and what clients should do.
>
> The problem is that if a client wants to do a pixfmt change
> it has to wait for an outstanding FramebufferUpdateRequest to
> be satisfied by a FramebufferUpdate. That's the only way be
> sure that the next requested FramebufferUpdate is in the
> expected pixfmt, as I'm sure you understand. Hmmm, perhaps
> not the only way, see below...
>
> The problem is that you seem to think that this is only a
> problem when using the Refresh Screen function in VNC Free
> Edition, while my position is that it is a generic protocol
> problem which puts unfortunate limitations on clients. So, if
> the following is true:
>
> 1. the client has an outstanding FramebufferUpdateRequest 2.
> the client has lost its visual framebuffer 3. the client
> screen depth has changed (likely to cause 2) 4. the client
> doesn't have a backup copy of the framebuffer 5. the server
> doesn't have any updates for a long time
>
> then the client will show a blank screen for "an indefinite
> period" as the spec puts it. It has to wait for the server
> before it can refresh with the new pixfmt. I think it is very
> valid for the client to want to change pixfmt and get an update *now*.
>
> Sure, it can send extra non-incremntal
> FramebufferUpdateRequests and then try to sort out when it
> can be sure that no more FramebufferUpdates are coming down
> the wire, but that is complex.
>
> The proposed solution in my previous mail is just so much
> simpler, and keeps in line with "implementing a client is
> made as simple as possible," again from the spec. Just
> compare to this complex alternative when you want to change
> pixfmt and get an update *now*:
>
> 1. Send a non-incremental FramebufferUpdateRequest for a small area.
> 2. Wait for a FramebufferUpdate.
> 3. If the update does not contain the requested area from 1, goto 7.
> 4. Send a non-incremental FramebufferUpdateRequest for another
>    (non-intersecting) small area.
> 5. Wait for a FramebufferUpdate.
> 6. If the update does contain the requested area from 4, goto 8.
> 7. Wait for a FramebufferUpdate.
> 8. Send SetPixelFormat.
> 9. Send full non-incremental FrameBufferUpdateRequest.
>
> Is there a simpler way to work around this without protocol
> additions such as new pseudo-encodings?
>
> Cheers,
> Peter
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

Peter Rosin
On Thu, Dec 13, 2007 at 12:40:11PM -0000, James Weatherall wrote:
> Peter,
>
> It is a limitation of the RFB 3.x protocol, which requires that update
> requests are required to be matched 1-to-1 by framebuffer updates, although
> this isn't strictly required if the pixel format isn't going to change.  It
> therefore affects VNC Free Edition & software based upon it.

Hi Wez,

Indeed, but to reiterate a previously unanswered question:

When the solution is a simple as introducing a pseudo-encoding that
gets sent (if requested of course) as an empty rect before any rect
with the new pixfmt is sent, why not introduce that?

(i.e. similar to the DesktopSize pseudo-encoding)

Cheers,
Peter

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

Anon Sricharoenchai-2
In reply to this post by Peter Rosin
On 12/13/07, Peter Rosin <[hidden email]> wrote:

> On Thu, Dec 13, 2007 at 10:09:07AM -0000, James Weatherall wrote:
> > Hi Anon & Peter,
> >
> > The VNC Personal & Enterprise Editions use a new scheme that does not have
> > this limitation.
> >
> > You won't hit problems with the VNC Free Edition system unless you send
> > multiple outstanding update requests (as is the case when using Refresh
> > Screen), *and* you change the on-the-wire pixel format *after* having done
> > that.

Hi James,

VNC non-free edition doesn't have this limitation, since it doesn't
have Refresh Screen function?
Or it implements a new RFB protocol that has not been published?
What scheme that the non-free edition use?

While the RFB protocol spec doesn't contain any mechanism or any
guides to cope with this problem, can you reveal the guides that is
used to solve this problem in non-free edition?

> You shouldn't need to use
> Refresh Screen, in general.

1. Although the user doesn't need to use Refresh Screen function, but
the thin client that lost its visual framebuffer (and no backup copy,
as stated by Peter) still need to refresh the screen by itself.
2. Although the pixfmt isn't changed by user, but it may be
automatically changed by the client itself, when the traffic quality
change.
3. What if the client lost its visual framebuffer, and the traffic
quality has changed, simultaneously?  The problem still exists in this
case.

>
> Hi Wez,
>
> I'm not talking about the VNC Free Edition system, I'm talking
> about the protocol and what clients should do.
>
> The problem is that if a client wants to do a pixfmt change it
> has to wait for an outstanding FramebufferUpdateRequest to be
> satisfied by a FramebufferUpdate. That's the only way be sure
> that the next requested FramebufferUpdate is in the expected
> pixfmt, as I'm sure you understand. Hmmm, perhaps not the
> only way, see below...
>
> The problem is that you seem to think that this is only a problem
> when using the Refresh Screen function in VNC Free Edition, while
> my position is that it is a generic protocol problem which puts
> unfortunate limitations on clients. So, if the following is true:
>
> 1. the client has an outstanding FramebufferUpdateRequest
> 2. the client has lost its visual framebuffer
> 3. the client screen depth has changed (likely to cause 2)
> 4. the client doesn't have a backup copy of the framebuffer
> 5. the server doesn't have any updates for a long time
>
> then the client will show a blank screen for "an indefinite
> period" as the spec puts it. It has to wait for the server before
> it can refresh with the new pixfmt. I think it is very valid for
> the client to want to change pixfmt and get an update *now*.
>
> Sure, it can send extra non-incremntal FramebufferUpdateRequests
> and then try to sort out when it can be sure that no more
> FramebufferUpdates are coming down the wire, but that is complex.
>
> The proposed solution in my previous mail is just so much simpler,
> and keeps in line with "implementing a client is made as simple
> as possible," again from the spec. Just compare to this complex

I agree with this.
The thin client with no backup copy of its framebuffer will frequently
need to refresh the screen by sending non-incremental update request.
It may possibly change the pixfmt on the fly, when network quality change.
This is the problem of RFB protocol, that the client can't change
pixfmt and request framebuffer update at the same time, otherwise, it
will be in an unstable state.

> alternative when you want to change pixfmt and get an update *now*:
>
> 1. Send a non-incremental FramebufferUpdateRequest for a small area.
> 2. Wait for a FramebufferUpdate.
> 3. If the update does not contain the requested area from 1, goto 7.
> 4. Send a non-incremental FramebufferUpdateRequest for another
>    (non-intersecting) small area.
> 5. Wait for a FramebufferUpdate.
> 6. If the update does contain the requested area from 4, goto 8.
> 7. Wait for a FramebufferUpdate.
> 8. Send SetPixelFormat.
> 9. Send full non-incremental FrameBufferUpdateRequest.
>
> Is there a simpler way to work around this without protocol additions
> such as new pseudo-encodings?

I think the best way is to define it in the core of the new version of
RFB protocol.
To just add the extension into existing RFB protocol, doesn't make the
other implementation of VNC client/server to aware of the important of
this extension.
The new version must state that the client should rely on the new
pixfmt only when the server explicitly confirm that the pixfmt has
been changed.
The client should NOT expect new pixfmt, just because it has sent the
setPixFmt to the server.

P.S. I just have found that I can't reproduce this bug (using the same
method) when connecting to Xvnc 3.3.7.  I don't know why, but I will
investigate for it.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel