RE: [Qemu-devel] [PATCH] Support VNC PointerTypeChange psuedo-encoding

[Ramesh Dharan]

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