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

[Anthony Liguori <anthony@codemonkey.ws>]

Ramesh Dharan wrote:
> 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. 
>   

Right, but how does your client determine that the server supports these 
new messages?

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 the new 
client message type.  This is what I'm using for my shared memory encoding.

Otherwise, there's no way to write a client that works with the 
"enhanced" server and a normal VNC server.

>> 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. 
>   

The mechanism I described above is what the current preferred method 
is.  If you want, we can bring the topic up with the VNC authors as 
AFAIK I'm the only person with a reserved client message type.  Of 
course, I think using a pseudo-encoding is a perfectly suitable way to 
address this problem.

Regards,

Anthony Liguori

> --
> Ramesh
>
>