From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJBCB-0003ap-0f for qemu-devel@nongnu.org; Fri, 11 Dec 2009 14:30:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJBC5-0003Tb-VA for qemu-devel@nongnu.org; Fri, 11 Dec 2009 14:30:30 -0500 Received: from [199.232.76.173] (port=36447 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJBC5-0003TQ-PM for qemu-devel@nongnu.org; Fri, 11 Dec 2009 14:30:25 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:50537) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJBC5-000409-F2 for qemu-devel@nongnu.org; Fri, 11 Dec 2009 14:30:25 -0500 Received: by yxe26 with SMTP id 26so1164582yxe.4 for ; Fri, 11 Dec 2009 11:30:24 -0800 (PST) Message-ID: <4B229DCE.7070500@codemonkey.ws> Date: Fri, 11 Dec 2009 13:30:22 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Spice project is now open References: <1393046876.1549021260539141025.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <4B226BFC.1040606@codemonkey.ws> <20091211204828.464707cf@redhat.com> <4B2297A2.8040102@codemonkey.ws> <20091211212135.645864f9@redhat.com> In-Reply-To: <20091211212135.645864f9@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Izik Eidus Cc: Yaniv Kamay , qemu-devel@nongnu.org Izik Eidus wrote: > I should speek with the marketing guys, will be able to answer on that > specific question in few days. > > > But simple 2D Commands are just not enougth for spice. > We have multiple drawing surfaces, that are depended on each other. > We Dont renender untill the very moment that the guest try to read its > video memory, we have video streaming, and we have cache based by the > guest driver. > We have private channels for stuff like keyboard, display and so on... > The video streaming is an encoding heuristic though, right? The lack of guest visible rendering is interesting. >> I'm not familiar with what a "depth viewing tree". Can you elaborate? >> > > In it simplest way of working, we will take the simplest case of what > it is doing: > If you have application that rendered a window, and then it renendered > another window on top of it, you dont want to send the commands that > rendered the old window, beacuse the new commands hide the older one... > Ah, this is unique to a windowing protocol. A framebuffer protocol does not have to worry about this because the OS does it for you. How well does this work with a Linux guest? To get a lot of this level of information, you have to hook in at the X protocol level (which is what NX does). Can you really do much at the X driver level? Of course, a lot of interesting stuff (like drawing ops and text rendering) doesn't even happen in the X server these days. >>> I think we should allow freedom of choice to the users to decide >>> what protcol they want to use, Spice and VNC are all diffrent and >>> were born to meet diffrent goals. >>> >>> >> What would be ideal, is if there was a mechanism whereas a client >> could connect to the VNC server, and get VNC traffic if it's a normal >> VNC client, but if it was a smarter client, got a more sophisticated >> stream. If that was something that was Spice or Spice-like, that >> would be perfect. >> >> But to introduce another protocol where a user has to make a choice >> to use Spice over VNC, I think we need a really good justification >> for that. It's really about complexity. A user shouldn't have to >> know about Spice or VNC. They shouldn't have to contemplate the >> trade-offs of whether their management tool is aware or not. It >> should Just Work. >> > > > This why we suggest the VDI interface, to solve all this choicses we > made for the users, > Okay, but it's hard to evaluate that suggestion without seeing the VDI interface :-) > Think about qemu give infastracture to multiple librarys to use it? > For example one user can use qemu with VNC, one with SPICE, and one > can use qemu with diffrent private local rendering soultion (for highly > fast local 3d rendering...) > As I said, I don't have a problem with externalizing things. I think there's some discussion about how best to do that. For instance, I think we want to avoid shared library plugins as it introduces a good deal of instability into our address space. Regards, Anthony Liguori