Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On Wed, Dec 12, 2007 at 01:50:38PM -, 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 lng 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 VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
RE: pixel format is out of sync, after refreshing and suddenly changing pixel format
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rosin Sent: 13 December 2007 08:43 To: James Weatherall Cc: 'Anon Sricharoenchai'; vnc-list@realvnc.com; [EMAIL PROTECTED] Subject: Re: pixel format is out of sync, after refreshing and suddenly changing pixel format On Wed, Dec 12, 2007 at 01:50:38PM -, 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 lng 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 VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
RE: pixel format is out of sync, after refreshing and suddenly changing pixel format
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Astrand
Sent: 12 December 2007 18:17
To: Anon Sricharoenchai
Cc: vnc-list@realvnc.com; [EMAIL PROTECTED]
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
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On Thu, Dec 13, 2007 at 10:09:07AM -, 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 ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
RE: pixel format is out of sync, after refreshing and suddenly changing pixel format
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:[EMAIL PROTECTED] Sent: 13 December 2007 12:16 To: James Weatherall Cc: 'Anon Sricharoenchai'; vnc-list@realvnc.com; [EMAIL PROTECTED] Subject: Re: pixel format is out of sync, after refreshing and suddenly changing pixel format On Thu, Dec 13, 2007 at 10:09:07AM -, 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 ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On Thu, Dec 13, 2007 at 12:40:11PM -, 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 ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On 12/13/07, Peter Rosin [EMAIL PROTECTED] wrote: On Thu, Dec 13, 2007 at 10:09:07AM -, 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. ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
RE: pixel format is out of sync, after refreshing and suddenly changing pixel format
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anon Sricharoenchai
Sent: 12 December 2007 12:25
To: vnc-list@realvnc.com;
[EMAIL PROTECTED]; [EMAIL PROTECTED]
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
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
___
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
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
[EMAIL PROTECTED]
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
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
This problem doesn't exist in VNC non-free edition?
On 12/12/07, James Weatherall [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anon Sricharoenchai
Sent: 12 December 2007 12:25
To: vnc-list@realvnc.com;
[EMAIL PROTECTED]; [EMAIL PROTECTED]
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
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
___
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
