From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ini6a-0000on-DZ for qemu-devel@nongnu.org; Thu, 01 Nov 2007 18:01:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ini6Y-0000ne-OH for qemu-devel@nongnu.org; Thu, 01 Nov 2007 18:01:36 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ini6Y-0000nb-I3 for qemu-devel@nongnu.org; Thu, 01 Nov 2007 18:01:34 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ini6Y-0005my-2l for qemu-devel@nongnu.org; Thu, 01 Nov 2007 18:01:34 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lA1M1Svu028162 for ; Thu, 1 Nov 2007 18:01:28 -0400 Received: from file.surrey.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lA1M1RfV011756 for ; Thu, 1 Nov 2007 18:01:27 -0400 Received: (from berrange@localhost) by file.surrey.redhat.com (8.13.1/8.13.1/Submit) id lA1M1RBK023323 for qemu-devel@nongnu.org; Thu, 1 Nov 2007 22:01:27 GMT Date: Thu, 1 Nov 2007 22:01:27 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Shared VNC sessions Message-ID: <20071101220126.GF749@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: "Daniel P. Berrange" , 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 On Thu, Nov 01, 2007 at 03:49:42PM -0600, Felipe Sanchez wrote: > > > Hi, in older versions of the RFB patch it was possible to connect multiple > VNC clients to the VNC framebuffer. With the current VNC support if I have > one connected client then any other trying to connect will block until the > first one disconnects. That is correct. I had a patch floating around somewhere to immediately drop the second connection instead of making it block forever, so at least client don't hang. > After a quick look at vnc.c it seems that the incoming connections are > handled via qemu's fd_handler function which I'm guessing is where the > blocking takes place, but I'm not really familiar with qemu's code so any > help would be greatly appreciated :-) The blocking isn't really anything todo with the fd handlers - the event loop can handle this kind of thing just fine. The problem is that the VNC server state is only capable of tracking dirty region updates for a single client at once. To support multiple clients will require some significant refactoring of the server state. Not impossible, but not a quick fix either. It just needs someone motivated enough to poke at it.... > Also: Does qemu's current VNC implementation support tight encoding? No. Raw or hextile. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|