From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HX7kt-0002QO-Vz for qemu-devel@nongnu.org; Thu, 29 Mar 2007 23:26:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HX7kq-0002L5-Ih for qemu-devel@nongnu.org; Thu, 29 Mar 2007 23:26:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HX7kq-0002L1-66 for qemu-devel@nongnu.org; Thu, 29 Mar 2007 22:26:20 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HX7iB-0005Ex-GA for qemu-devel@nongnu.org; Thu, 29 Mar 2007 23:23:35 -0400 Received: by wx-out-0506.google.com with SMTP id i30so574272wxd for ; Thu, 29 Mar 2007 20:23:35 -0700 (PDT) Message-ID: <460C82B3.2080600@codemonkey.ws> Date: Thu, 29 Mar 2007 22:23:31 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Support VNC PointerTypeChange psuedo-encoding References: <34BDD2A93E5FD84594BB230DD6C18EA2EBE937@nuova-ex1.hq.nuovaimpresa.com> <4606AF6E.9010000@codemonkey.ws> <460C7802.5070503@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ramesh Dharan Cc: qemu-devel@nongnu.org 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 > >