xvncviewer dies talking to Mac OSX

Bug #138935 reported by Matthias Urlichs
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tightvnc (Debian)
New
Undecided
Unassigned
vnc (Ubuntu)
Confirmed
Low
Unassigned
vnc4 (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

xvnc4 has the same problem. :-(

smurf@kiste ~ $ xrealvncviewer minimac
VNC viewer version 3.3.7 - built May 24 2007 12:45:44
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.889 (viewer 3.3)
Password:
VNC authentication succeeded
Desktop name "MiniMac.local"
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
Using shared memory PutImage
Unknown message type 160 from VNC server
ShmCleanup called

Revision history for this message
Matthias Urlichs (smurf) wrote :

smurf@kiste ~ $ xvncviewer minimac.bismarck

VNC Viewer Free Edition 4.1.1 for X - built Sep 10 2007 17:17:04
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Tue Sep 11 19:26:20 2007
 CConn: connected to host minimac.bismarck port 5900
 CConnection: Server supports RFB protocol version 3.889
 CConnection: Using RFB protocol version 3.8

Tue Sep 11 19:26:23 2007
 TXImage: Using default colormap and visual, TrueColor, depth 24.
 CConn: Using pixel format depth 6 (8bpp) rgb222
 CConn: Using ZRLE encoding
unknown message type 160

Tue Sep 11 19:26:24 2007
 main: unknown message type

Revision history for this message
Brian Simons (brians-mediarain) wrote :

I'm seeing the same problem. I can connect successfully using xtightvncviewer 1.2.9-21, but not with xvncviewer 3.3.7-13ubuntu2

VNC viewer version 3.3.7 - built Mar 8 2007 21:56:52
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.889 (viewer 3.3)
Password:
VNC authentication succeeded
Desktop name "DHP.local"
Connected to VNC server, using protocol version 3.3
VNC server default 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
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
Using shared memory PutImage
Throughput 9768 kbit/s - changing from 8bit
Using viewer's native pixel 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
Unknown message type 255 from VNC server
ShmCleanup called

Revision history for this message
Alessandro Polverini (polve) wrote :

I have the same problem, on Gutsy, tried with all these packages:
xvncviewer
xvnc4viewer
xtightvncviewer

Revision history for this message
tebeka (miki-tebeka) wrote :

I see the same problem.

The tightvnc viewer (http://www.tightvnc.com/download.html) works fine (installed from sources).

Revision history for this message
perpeden (perpeden) wrote :

This may be a result of the default color settings in vnc, try this:

vncviewer FullColor=1 <ipaddress>

From the messages above, this should allow it to work for you.

Revision history for this message
Kirby (usawebbox) wrote :

Yes, that does fix it. Sadly, there is no way to select that option in tsclient-applet 0.150

Of course, it still means that auto-negotiation and support for lower rate modes is not working, either in xvnc4viewer or on the Mac side.

Revision history for this message
Daniel T Chen (crimsun) wrote :

Lowering severity due to extant workaround.

Changed in vnc:
importance: Undecided → Low
Changed in vnc4:
importance: Undecided → Low
Revision history for this message
Philippe Coval (rzr) wrote :

@ Alessandro Polverini wrote on 2008-02-04: (permalink)
> I have the same problem, on Gutsy, tried with all these packages:
> xtightvncviewer

It works for me , here is my trace if it helps :

<pre>
  Connected to RFB server, using protocol version 3.8
  Performing standard VNC authentication
  Password:
  Authentication successful
  Desktop name "eac"
  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 which is TrueColor. Pixel 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
</pre>

I only have issue with the clipboard...

Revision history for this message
alan ezust (alan-ezust) wrote :

i have the same problem with debian lenny and these clients, while trying to talk to 2 different macs using desktopsharing.

Xtightvncviewer Version: 1.3.9-4
Vinagre Version: 0.5.1-2
xvnc4viewer Version: 4.1.1+X4.3.0-31 FullColor=1
xvncviewer Version: 4.1.1+X4.3.0-31 FullColor=1

Revision history for this message
alan ezust (alan-ezust) wrote :

reproduced using krdc also

Revision history for this message
alan ezust (alan-ezust) wrote :

Current workaround is to use either

jtightvncviewer or gvncviewer

Neither of them seem to exhibit these problems connecting to macos.

Revision history for this message
Gustav Svensson (gustav-svensson) wrote :

Using perpeden's solution fixes the problem for me:
vncviewer FullColor=1 <ipaddress>

Revision history for this message
Ed (classicmacintosh) wrote :

If I remember Mac OS X's VNC server does not support 32-bit colour... thus you need to set VNC to use 16-bit colour.

I feel that patching VNC to use 16-bit colour by default should fix this issue, whilst not losing existing compatibility.

Revision history for this message
Thomas Hotz (thotz-deactivatedaccount) wrote :

Confirming because this happens to several users.

Changed in vnc4 (Ubuntu):
status: New → Confirmed
Changed in vnc (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.