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

[Anthony Liguori <anthony@codemonkey.ws>]

Ramesh Dharan wrote:
>> 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.
>>     
>
> Ok, yeah that makes sense. So yeah basically we would need to add new server
> encodings for our client->server messages, and then you get the server to
> send dummy "ack" messages for each one to say "yes, I understand this message
> type"?
>   

Yup.

>> 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.
>>     
>
> Yeah the only problem I see with it is that I don't see how the server can
> dynamically *change* the set of client messages that it accepts?
>   

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 SetServerEncodings message)?

I think it's easier to just add something to the psuedo-encoding to 
allow client messages that make sense to disable to be disabled on a 
case-by-case basis.

Regards,

Anthony Liguori

> --
> Ramesh
>
>