From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HX72k-00061o-AR for qemu-devel@nongnu.org; Thu, 29 Mar 2007 22:40:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HX72h-00061c-VW for qemu-devel@nongnu.org; Thu, 29 Mar 2007 22:40:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HX72h-00061Z-PI for qemu-devel@nongnu.org; Thu, 29 Mar 2007 21:40:43 -0500 Received: from wx-out-0506.google.com ([66.249.82.231]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HX703-000056-9v for qemu-devel@nongnu.org; Thu, 29 Mar 2007 22:37:59 -0400 Received: by wx-out-0506.google.com with SMTP id i30so562426wxd for ; Thu, 29 Mar 2007 19:37:58 -0700 (PDT) Message-ID: <460C7802.5070503@codemonkey.ws> Date: Thu, 29 Mar 2007 21:37:54 -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> 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: > 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 > >