> To do it in general? Yeah, I don't think there's a solution. Of
> course, a SetServerEncodings would introduce a race. What does the
> server do if it receives one of the new special client messages after
> sending the SetServerEncodings message (but before the client
> receives
> the Se
> The proper way to use new client message types (which is now
> described
> in the RFB spec) is to advertise a new pseudo-encoding for
> that client
> message type and wait for the server to send the
> pseudo-encoding back to
> the client. That lets the client know that it is safe to use th
Hi Anthony, sorry for the delayed response to your delayed response.
I actually haven't been working much on the remote display stuff in a while,
though it's something I'm hoping to get involved with again time permitting.
I'm cc'ing Dustin Byford and Johnson Liu, VMware engineers who handle a lot
Anthony, I have a detailed response to your earlier e-mail but I wanted to
handle this discussion separately.
> > I implemented new client->server messages for the (1) and (2), and
>
> I should have read more carefully. This means that you're not a
> compliant RFB server ATM.
I'm not sure I f
> [EMAIL PROTECTED] wrote:
> > This extension is documented at
> > http://tocm.wikidot.com/pointertypechange
>
> VMware has a very similar extension for their remote console. I
> believe
> that Ramesh Dharan (whom I've CCed) at some point implemented it in o
