Sorry, now we're inverted with "Let Server Decide" on Window RealVNC,
On Apr 7, 2005, at 4:32 PM, Sean Kamath wrote:
> OK, I *think* I found it. But I can't be 100% sure.
> What looks to be happening is sort of a double-shifting. We shift
> once with pixelFormat, and then again in cvt_pixel24. So I simply
> commented out the endian check in cvt_pixel24, and I can confidently
> say that this fixed the TightVNC bug (both tight encoding and ZRLE
> encoding). It *doesn't* break OSXvnc. And it doesn't break realVNC
> on Solaris (handily, the solaris realvnc server lets you specify the
> pixelformat. :-)).
> What I *can't* test (easily. I may set up to be able to test
> this. . .) is what it does with any version of a windows server. It
> may break it horribly.
> The realvnc viewer doesn't let you specify tight encoding only (ZRLE,
> Hextile and Raw are it).
> I committed the change. If you find it *does* break something, then
> a) let me know, and b) (if you know why) tell me why. :-)
> BTW: This also explains (somewhat) why it breaks with using server
> specified pixelformat only.
> [In a message on Thu, 07 Apr 2005 15:15:15 PDT,
> Sean Kamath wrote:]
>> [In a message on Thu, 07 Apr 2005 04:54:04 PDT,
>> Jason Harris wrote:]
>>> On Apr 6, 2005, at 11:21 PM, Sean Kamath wrote:
>>>> Yeah, it's still there. I just checked it with a checkout from 5
>>>> minutes ago.
>>> Sean, take a look at the bug report for this. I've put a bit more
>>> there on stuff you can do so I can help you track this down.
>> OK, I'll check it out. It's really weird. I'm beginning to wonder if
>> tightvnc is doing something it shouldn't (oddly, when I run vncviewer
>> on solaris, it says tightvnc on linux is using big-endian encoding.
>> Yow. . . I'm downloading and trying realvnc 4.1.1 on my Virtual PC
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> Discover which products truly live up to the hype. Start reading now.
>> cotvnc-devel mailing list