#108 Strange colour map connecting to tightVNC

v2.0
closed-fixed
None
5
2005-08-23
2004-10-07
Anonymous
No

Well this problem went away with 2.0-b1 but it came
right back with 2.0-b2. See <a
href="http://sourceforge.net/tracker/index.php?func=detail&aid=787943&group_id=64347&atid=507159">bug
787943</a> for full description.

Discussion

  • Jon McAuliffe

    Jon McAuliffe - 2004-10-17

    Logged In: YES
    user_id=842290

    i'm having the same problem. is this easy to fix?

     
  • Jason Harris

    Jason Harris - 2004-12-08
    • assigned_to: nobody --> smeger
     
  • Jason Harris

    Jason Harris - 2004-12-08

    Logged In: YES
    user_id=351330

    I believe that this is fixed in CVS for 2.0b3, but I don't have a little-
    endian server to test against. If you're down for it, please pull CVS and
    test.

     
  • Nobody/Anonymous

    Logged In: NO

    Pulled CVS HEAD at 2004-12-13, I'm still seeing red and blue
    swapped :(

     
  • Jason Harris

    Jason Harris - 2004-12-13

    Logged In: YES
    user_id=351330

    Please post the messages that are logged to console when you connect to
    the problematic server. You can find these by opening /Applications/
    Utilities/Console.

     
  • Nobody/Anonymous

    Logged In: NO

    This is all I get:

    2004-12-14 16:14:21.995 Chicken of the VNC[763] supported
    encodings changed, upgrading profile
    2004-12-14 16:15:39.693 Chicken of the VNC[771] Server
    reports Version RFB 003.003
    2004-12-14 16:15:39.920 Chicken of the VNC[771] Transport
    Pixelformat:
    2004-12-14 16:15:39.921 Chicken of the VNC[771]
    trueColor = YES
    2004-12-14 16:15:39.921 Chicken of the VNC[771]
    bigEndian = NO
    2004-12-14 16:15:39.921 Chicken of the VNC[771]
    bitsPerPixel = 32
    2004-12-14 16:15:39.921 Chicken of the VNC[771]
    depth = 24
    2004-12-14 16:15:39.922 Chicken of the VNC[771]
    maxValue(r/g/b) = (255/255/255)
    2004-12-14 16:15:39.922 Chicken of the VNC[771]
    shift(r/g/b) = (16/8/0)
    rfbPixelFormat redMax = 255
    rfbPixelFormat greenMax = 255
    rfbPixelFormat blueMax = 255

     
  • Sean Kamath

    Sean Kamath - 2004-12-15

    Logged In: YES
    user_id=955479

    OK, I just test the latest MAIN branch (I assume -- I pulled
    down the latest with no TAG), and tested against RealVNC 4.0
    on both a PC (running Windows XP SP2) and a Sun (Solaris 9).
    Both were running in 24-bit mode.

    No problems.

    Can you please post any log information from TightVNC
    showing what TightVNC thinks the connection is set up for?
    Also, what does your connection profile look like? Also,
    what is the depth and size of the monitor on the remote PC
    (I assume it's a PC).

    If you can narrow it down to what time of encoding is being
    used, that would help (I created a profile for each encoding
    type and tested each one individually).

     
  • Jason Harris

    Jason Harris - 2004-12-15

    Logged In: YES
    user_id=351330

    Sean, note that this bug is against a server running on _Linux_ on a
    little-
    endian machine. The original bug referenced above gives more details.

     
  • jjdmon

    jjdmon - 2005-01-07

    Logged In: YES
    user_id=1116569

    I see the red-blue switch connecting to a tightVNC server on 'Blue' Hat
    Linux. It happens with the 2.0b3 release version of cotVNC as well as the
    latest from CVS as of 1/6/05. VNC gives me probably a 10x speed
    improvement over X-forwarding due to the high latency of my connection
    (about 200ms round trip ping) so I will probably use it even with the color
    inversion. Is there somewhere in the code I could easily force a reversal
    back to the real colors in my local copy?

     
  • Jason Harris

    Jason Harris - 2005-01-07

    Logged In: YES
    user_id=351330

    jjdmon, I don't know where the bug is occurring, otherwise, I'd have
    fixed it. :)

    And I don't have an intel linux box to test against.

    Some things to try for a work-around. In Chicken's Connection Profiles
    window, play with the Color settings. Specifically, try switching between
    "Let Server Decide" and "Millions of Colors".

    If you want to play with code, search the code for color "shift" values.
    I'd be interested in finding out anything you discover.

     
  • Jon McAuliffe

    Jon McAuliffe - 2005-01-07

    Logged In: YES
    user_id=842290

    i worked around this by setting the color depth to 16 bit when i launch
    the tightvnc server. then there's no inversion. (a clue to the problem?)

     
  • jjdmon

    jjdmon - 2005-01-07

    Logged In: YES
    user_id=1116569

    Since this keeps popping up and is hard to debug, how about adding a
    reverse blue and red option to the connection profile so if it happened it
    could be fixed manually.

     
  • jjdmon

    jjdmon - 2005-01-07

    Logged In: YES
    user_id=1116569

    Ok, manually setting the color depth to millions of colors fixed it. Guess I
    don't have to play with code then. Thanks.

     
  • Sean Kamath

    Sean Kamath - 2005-01-08

    Logged In: YES
    user_id=955479

    I'm in the process of debugging this. However, I'm having
    some problems on the Linux box (rpm keeps coring on me). In
    anycase, it would be VERY helpful to know a couple of things
    to help narrow this down:

    Command line invokation of TightVNC
    Profile selections in CotVNC (I.e., what encodings are
    enabled in what order)
    Color selection in CotVNC.

     
  • Sean Kamath

    Sean Kamath - 2005-01-08

    Logged In: YES
    user_id=955479

    Found a problem with TightVNC 1.2.9 on RedHat 7.3. "tight"
    encoding with 24bpp is inverted.

     
  • Jason Harris

    Jason Harris - 2005-01-08

    Logged In: YES
    user_id=351330

    Sean, take a look at the URI for the original bug report, that gives the
    command line invocation. The URI is at the top of this report.

    I believe that this issue occurs only when the encoding is Tight or ZRLE,
    and the color mode in Chicken is set to Millions or Let Server Decide.

    The main problem, I think, is that the VNC server on a little-endian Linux
    box reports the same "please use these settings" parameters as stuff
    that works properly now - RealVNC on Windows and OSXVnc on OS X.
    Fixing one will probably break another.

     
  • Sean Kamath

    Sean Kamath - 2005-01-08

    Logged In: YES
    user_id=955479

    Indeed, it does. Sure enough it's the depth 24 bug. I'm
    assuming the tight encoding is the issue here, since which
    encoding is being used is not specified. I think we should
    put in the RFB info window which encoding they're currently
    using. . .

     
  • Jason Harris

    Jason Harris - 2005-04-07

    Logged In: YES
    user_id=351330

    Unfortunately, a server that works (Windows RealVNC) is reporting the
    same shift settings as the broken server referenced in this bug report by
    "nobody" on 2004-12-14. For the record, here's the log from a working
    server, using Tight encoding:

    Server reports Version RFB 003.008
    Transport Pixelformat:
    trueColor = YES
    bigEndian = NO
    bitsPerPixel = 32
    depth = 24
    maxValue(r/g/b) = (255/255/255)
    shift(r/g/b) = (16/8/0)
    rfbPixelFormat redMax = 255
    rfbPixelFormat greenMax = 255
    rfbPixelFormat blueMax = 255

    What would be useful would be to see log entries like the above for both
    working cases and for inverting cases, connecting to the same server. For
    each log entry, I'd also like to know whether the profile color is set to "Let
    Server Decide" or "Millions of Colors".

     
  • Nobody/Anonymous

    Logged In: NO

    I pulled HEAD from 8-Apr. Bug seems to be resolved in that
    build.
    Here are the logs from that version (working):
    2005-04-16 14:30:01.247 Chicken of the VNC[688] Server
    reports Version RFB 003.003
    2005-04-16 14:30:01.354 Chicken of the VNC[688] Transport
    Pixelformat:
    2005-04-16 14:30:01.354 Chicken of the VNC[688] trueColor = YES
    2005-04-16 14:30:01.354 Chicken of the VNC[688] bigEndian = NO
    2005-04-16 14:30:01.354 Chicken of the VNC[688]
    bitsPerPixel = 32
    2005-04-16 14:30:01.354 Chicken of the VNC[688] depth = 24
    2005-04-16 14:30:01.354 Chicken of the VNC[688]
    maxValue(r/g/b) = (255/255/255)
    2005-04-16 14:30:01.355 Chicken of the VNC[688]
    shift(r/g/b) = (16/8/0)
    rfbPixelFormat redMax = 255
    rfbPixelFormat greenMax = 255
    rfbPixelFormat blueMax = 255

    Here are the logs from 2.0b2 (not working)
    2005-04-16 14:33:52.131 Chicken of the VNC[694] Server
    reports Version RFB 003.003
    2005-04-16 14:33:52.238 Chicken of the VNC[694] Transport
    Pixelformat:
    2005-04-16 14:33:52.238 Chicken of the VNC[694] trueColor = YES
    2005-04-16 14:33:52.238 Chicken of the VNC[694] bigEndian = NO
    2005-04-16 14:33:52.238 Chicken of the VNC[694]
    bitsPerPixel = 32
    2005-04-16 14:33:52.239 Chicken of the VNC[694] depth = 24
    2005-04-16 14:33:52.239 Chicken of the VNC[694]
    maxValue(r/g/b) = (255/255/255)
    2005-04-16 14:33:52.239 Chicken of the VNC[694]
    shift(r/g/b) = (16/8/0)
    rfbPixelFormat redMax = 255
    rfbPixelFormat greenMax = 255
    rfbPixelFormat blueMax = 255

    Hmm, they look kind of similar. In both cases, the
    connection profile is set to "Let Server Decide"

    Here's some more info:
    - With 2.0b2 setting the nmber of colours manually to
    Thousands or 256 gives correct results. Setting to "let
    server decide" gives the bug as referenced. However,
    setting to Millions produces neither the correct behaviour
    nor the behaviour in the bug! I get what looks like the
    correct colours, with the addition of a yellow filter??

    - With the HEAD version, I get correct results at any colour
    resolution

    Here is the log from the server (HEAD version of COTVNC,
    "Let Server Decide"):
    16/04/05 15:03:52 Got connection from client 192.168.200.5
    16/04/05 15:03:52 Protocol version 3.3
    16/04/05 15:03:52 Full-control authentication passed by
    192.168.200.5
    16/04/05 15:03:52 Pixel format for client 192.168.200.5:
    16/04/05 15:03:52 32 bpp, depth 24, little endian
    16/04/05 15:03:52 true colour: max r 255 g 255 b 255,
    shift r 16 g 8 b 0
    16/04/05 15:03:52 no translation needed
    16/04/05 15:03:52 rfbProcessClientNormalMessage: ignoring
    unknown encoding 16
    16/04/05 15:03:52 Using tight encoding for client 192.168.200.5
    16/04/05 15:03:52 rfbProcessClientNormalMessage: ignoring
    unknown encoding 8

    Let me know if there's anything else you need ...

     
  • Jason Harris

    Jason Harris - 2005-04-26
    • status: open --> open-fixed
     
  • Jason Harris

    Jason Harris - 2005-04-26

    Logged In: YES
    user_id=351330

    Okay, finally fixed in CVS. Verified against OSXVnc on Tiger and Jaguar,
    RealVNC on Windows, TightVNC on Windows, RealVNC on Intel, and
    tightvnc 3.3 and 3.7 on Intel. Verified using "Let Server Decide",
    "Millions", "Thousands" and "256" colors.

    For the record, the issue was that a footnote in the Tight Encoding spec
    says that if the depth is 24-bits and the color channels are 8-bit, the
    encoding order is always RGB, regardless of the endianness.

    Leaving open until we ship.

     
  • Nobody/Anonymous

    Logged In: NO

    > Leaving open until we ship.

    You got an estimated timeframe for that (apart from "when
    it's ready" ;)? Not pushing, just curious ...

     
  • Jason Harris

    Jason Harris - 2005-05-03

    Logged In: YES
    user_id=351330

    "When it's ready." :)

    But, no, not really. We were discussing it on the dev mailing list and it
    looks like there's one outstanding large bug and one outstanding small
    one.

     
  • Jason Harris

    Jason Harris - 2005-08-23

    Logged In: YES
    user_id=351330

    Resolved for Chicken 2.0b3.

     
  • Jason Harris

    Jason Harris - 2005-08-23
    • status: open-fixed --> closed-fixed
     

Log in to post a comment.