Chicken of the VNC

Logged In: YES
user_id=351330

Resolved for Chicken 2.0b1. Closing, finally, whoo!

Logged In: NO


Hi

i'm running the following :

viewer >> COTVNC 1.3.6 on OS X 10.3.3

server >> RealVNC 3.3.7 on Win2k

experiencing the similar problem

solution : the server has be in 16-bit colour display mode / the viewer
can be in any display mode


cheers

Logged In: YES
user_id=351330

Update: As far as I can tell, this is now fixed in GEN_2_GUI branch of
CVS.

Tested against RealVNC and OSXVNC 1.33.

I'll leave this bug open until we put out a public build, though.

Logged In: YES
user_id=864970

dito with subencoding 51

Logged In: YES
user_id=351330

Bob, first off, great work on finally cracking this bug open.

I've began investigating this, and for me, changing FrameBuffer.m:342 to
(pixelFormat.depth >= 24) &&
as per your original patch works perfectly with OSXVnc 1.32 and with
RealVNC 3.3.7.

What problems were you having that necessitated the more complicated
patch? Bring me up to speed.

Logged In: NO

TightVnc behaves like OSXvnc. It really seems (IMHO) that
this bug is a RealVnc bug, not a cotvnc bug.
Other clients may be OK because they might ask for a 24 bits
depth explicitly instead of a 32 bits depth when using true
colour.
--
bob (at) ophiuchus (dot) org

Logged In: YES
user_id=855597

Setting the bit depth to 8 bit in the profile works as a workaround
althouth 8 bit sucks.

Logged In: NO

There are still issues with OSXvnc that my last patch didn't
fix.
OSXvnc sends depth: 32 and CPixel: 4bytes and RealVnc send
depth: 32 and CPixel: 3bytes.
I can't decide which one is right, so I've come to a bastard
solution:
If the server is a bigendian one (OSXvnc for example), it
uses the strict definition from the rfb protocol (3 bytes
CPixel for a depth of 24 only).
Else it uses the laxist RealVnc definition (3 bytes CPixel
whenever possible).
New patch :
diff --unified=3 -r1.4 FrameBuffer.m
--- FrameBuffer.m 17 Jan 2003 11:55:52 -0000 1.4
+++ FrameBuffer.m 11 Mar 2004 23:53:35 -0000
@@ -338,11 +338,14 @@

- (unsigned int)tightBytesPerPixel
{
- if((pixelFormat.bitsPerPixel == 32) &&
- (pixelFormat.depth == 24) &&
- (pixelFormat.redMax == 0xff) &&
- (pixelFormat.greenMax == 0xff) &&
- (pixelFormat.blueMax == 0xff)) {
+ if((pixelFormat.trueColour == 1) &&
+ (pixelFormat.depth == 24 || pixelFormat.bigEndian ==
0) &&
+ (((pixelFormat.redMax << pixelFormat.redShift) <
(1<<24) &&
+ (pixelFormat.greenMax << pixelFormat.greenShift) <
(1<<24) &&
+ (pixelFormat.blueMax << pixelFormat.blueShift) <
(1<<24)) ||
+ ((pixelFormat.redShift > 7) &&
+ (pixelFormat.greenShift > 7) &&
+ (pixelFormat.blueShift > 7)))) {
return 3;
} else {
return bytesPerPixel;
--
bob (at) ophiuchus (dot) org

Logged In: YES
user_id=855597

Still the same with 10.3.2 and COTVNC 1.3.6 to Win XP and RealVNC
3.3.7

Zlibhex unknown subencoding 88 encountered

Logged In: NO

My first attempt to fix this bug is not very good since it
don't work with some VNC server.
I've looked at the sources of RealVNC client, and I propose
a new patch to fix this bug (cvs diff -u) :

--- FrameBuffer.m 17 Jan 2003 11:55:52 -0000 1.4
+++ FrameBuffer.m 10 Mar 2004 20:57:11 -0000
@@ -338,11 +338,13 @@

- (unsigned int)tightBytesPerPixel
{
- if((pixelFormat.bitsPerPixel == 32) &&
- (pixelFormat.depth == 24) &&
- (pixelFormat.redMax == 0xff) &&
- (pixelFormat.greenMax == 0xff) &&
- (pixelFormat.blueMax == 0xff)) {
+ if((pixelFormat.trueColour == 1) &&
+ (((pixelFormat.redMax << pixelFormat.redShift) <
(1<<24) &&
+ (pixelFormat.greenMax << pixelFormat.greenShift) <
(1<<24) &&
+ (pixelFormat.blueMax << pixelFormat.blueShift) <
(1<<24)) ||
+ ((pixelFormat.redShift > 7) &&
+ (pixelFormat.greenShift > 7) &&
+ (pixelFormat.blueShift > 7)))) {
return 3;
} else {
return bytesPerPixel;

--
bob (at) ophiuchus (dot) org

Logged In: NO

Hello,
I've made my own investigation on this problem, and I'm
concluding there is a mistake in the RFB Protocol.
Section 6.4.6, it says :
"ZRLE makes use of a new type CPIXEL (compressed pixel).
This is the same as a PIXEL for the agreed pixel format,
except where true-colour-flag is non-zero, bitsper-pixel is
32, *depth is 24 or less* and all of the bits making up the
red, green and blue intensities fit in either the least
significant 3 bytes or the most significant 3 bytes. In this
case a CPIXEL is only 3 bytes long, and contains the least
significant or the most significant 3 bytes as appropriate.
is the number of bytes in a CPIXEL."
I'm almost sure it should say "depth is 24 or more" instead
of "depth is 24 or less"
I've changed FrameBuffer.m:342 to
(pixelFormat.depth >= 24) &&
and now it runs well with my profile set to Server Native.
You can join me at bob (at) ophiuchus (dot) org

Logged In: YES
user_id=351330

I did some heavy lifting on this yesterday, trying to fix the issue.
It's still not fixed, but I've made progress. First, the ZRLEE code is
now up-to-date with the algorithms used in the RealVNC viewer.
The problem seems to be in the true-color (32-bit) framebuffer - I
only get the error when I have my profile set to Server Native.
Moving it to 24-bit, 16-bit or 8-bit fixes the issues.

Gonna dive back in, but wanted to post progress since there are a
few new posts on this today.

Logged In: NO

I got the same error with 1.3.6 trying to reach a PC with 3.3.7
except the subencoding number was 129.

Logged In: NO

I was getting a problem similar to those listed. ZlibHex 95 was
most often my number.

I resolved this by changing the Server computer (running XP)
from 32bit to 16bit colour quality. That resolved my problem.

Logged In: YES
user_id=898308

Just to add another datapoint, I get this same error (which is
remedied by using the suggested workaround) when connecting
to a VNC server running on Solaris. Here's part of the server
log, so you can tell what server I'm running:

10/12/03 07:57:07 Xvnc version 3.3.4 - built Sep
20 2002 15:28:59
10/12/03 07:57:07 Copyright (C) 2002 RealVNC Ltd.
10/12/03 07:57:07 Copyright (C) 1994-2000 AT&amp;T Laboratories
Cambridge.
10/12/03 07:57:07 Protocol version supported 3.3

Good luck nailing this down....

Logged In: YES
user_id=351330

Quickie update - fixing this is _not_ trivial since it seems
to be an issue with RealVNC adding their own twist to the
VNC spec rather than something wrong in Chicken. It's not
insurmountable, of course, but I don't get much time to work
on Chicken, so it's taking a long time to fix since it
involves figuring out what the hell the RealVNC people are
trying to do.

To answer johndoe_sf's question, I'd recommend using Chicken
1.3.6 and turning off the various zlib encodings rather than
using Chicken 1.3.1. 1.3.6 fixed lots of other things that
were issues in 1.3.1.

In fact, if you have the know-how, you should probably be
running the CVS version as it's stable and has a few new
features. All that's holding back a public release from CVS
is this zlib issue.

Logged In: YES
user_id=836015

don't know if there's any movement on this, but i've
encountered this as well (except using RealVNC server 3.3.7
&amp; getting subencoding 127 instead of 23).

i've already backed out to CotVNC 1.3.1 to solve the problem
for myself. any comment on whether it would be better to
stick with 1.3.1 or to move on to 1.3.6 and use the
workaround mentioned in the comment of smeger_2003-04-23?

Logged In: YES
user_id=351330

I've done some checking on this and it appears that RealVNC on Windows
(version 3.3.7) is sending illegal values for the ZRLE pixel subencoding.
I
think it'll be easy to hack Chicken so it's not a problem, I just need a
bit
more time connected to a Windows box for testing.

In the meantime, it appears from my testing that you can work around this

by changing RFB-Pixelformat in your profile to 8-bit. If you do this, you
can
keep all of the encoding enabled. This is good idea regardless, because
it
dramatically speeds up interaction with the remote machine.

Hopefully I'll have a fix in a few days.

Logged In: YES
user_id=370885

I received this error message when trying to connect to
RealVNC 3.3.7 running on a Windows 98 server. I don't know
if this is a limitation of the client or the server.
Anyway, to get around this problem, go into the Profiles
menu and make sure the following encoding options are set to
&quot;NO&quot;:

Zlib
ZRLE
ZlibHex
HexTile

Logged In: YES
user_id=351330

I'll check this out next time I dig into Chicken. I
probably just broke something while I was tweaking
perfomance and memory leaks for last release.

Logged In: YES
user_id=40562

p.s. This is the same bug as 684338.

Logged In: YES
user_id=40562

More Info:

Did a little fiddling, and discovered that the problem occurs when I have
ZRLE enabled. I have all the other options enabled except for ZRLE. When I
enable ZRLE and try to connect, I get the error.

Logged In: YES
user_id=40562

Additional comment: I can see that on the remote computer it is
registering (it is across the room from me, for testing purposes). When
COTVNC first makes the connection, I see a large black window, and on the
other computer I can see the pointer moving around if I move the mouse on
my local computer. But before drawing anything on the screen, the window
disappears and I get a message similar to the one I describe above.
Subencoding &quot;number&quot; differs each time (not always 23).