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 follow you. We support standard VNC clients, and we don't violate the protocol expectations of any standard VNC clients who talk to us. However, if a client *happens* to send us these new client->server messages (which don't exist in the standard spec), then we support them. We never send a message to a client that the client doesn't know how to handle. > I guess that means there isn't a point registering the > pseudo-encodings > you are currently using since you have to change the server/client > anyway. It's easier anyway since pseudo-encodings are supposed to be > negative numbers and you're using positive numbers. No, there's still a point. The display path and input path are essentially independent. Better input handling requires extending the client->server path (so the client can send new kinds of data other than the standard VNC keyboard and pointer events). Unfortunately, extension of the protocol in this direction was not baked into the original design. I think that basically we should actually extend the RFB protocol itself to just have a server->client message, SetSupportedClientMessages, which works exactly the way SetEncodings works today, i.e. the server can send down to the client a list of the messages which it can handle, and clients should not send message types to the server if the server doesn't support them. -- Ramesh
