From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVWRU-0002RP-TA for qemu-devel@nongnu.org; Sun, 25 Mar 2007 13:23:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVWRS-0002Qw-TQ for qemu-devel@nongnu.org; Sun, 25 Mar 2007 13:23:44 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVWRS-0002Qp-Ly for qemu-devel@nongnu.org; Sun, 25 Mar 2007 12:23:42 -0500 Received: from wx-out-0506.google.com ([66.249.82.228]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HVWPH-0002qe-Ls for qemu-devel@nongnu.org; Sun, 25 Mar 2007 13:21:28 -0400 Received: by wx-out-0506.google.com with SMTP id i30so2820333wxd for ; Sun, 25 Mar 2007 10:20:49 -0700 (PDT) Message-ID: <4606AF6E.9010000@codemonkey.ws> Date: Sun, 25 Mar 2007 12:20:46 -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> 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: qemu-devel@nongnu.org Cc: Ramesh Dharan Ramesh Dharan wrote: > 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 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. I'm happy to start looking at reimplementing your encodings using my pseudo-encoding range. It should be real easy for ya'll to support these too. I'll spend a little time in the next week enumerating these extensions and assigning proper values to them. Do you have any documentation on your currently client messages? Those aren't documented as part of the FFMPEG project. Regards, Anthony Liguori > server->client pseudorectangle extensions for (3) and (4). We deal with (5) > in a different way; our display multiplexing is handled at a higher level. We > ignored (6) since our clients currently only talk to our servers. > > Looking at the linked site, it looks like you folks have already identified > and are planning to deal with (2), possibly (5) (via some games with the > display name?) and (6). I'd be particularly interested to hear more about > plans for how to address (5), it would be great if off-the-shelf/3rd-party > clients could talk to multiple VMs running on a host without needing to know > and use a separate the port for each VM. > > Our remote consoles/clients are heavily tied to our products and there aren't > any real plans to divest them or make them more generally useful in the near > future. However, that's likely to change someday, and anyway I'd be happy to > provide feedback on, and implement support for these extensions so that e.g. > a QEMU client could talk to a VMware instance, and in general get > standardization to the point where it's possible to build a single remote > client that could talk to the various VM implementations (QEMU, Xen, VMware, > etc.). > > -- > Ramesh > > > >