From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLJAH-0007nj-Ax for qemu-devel@nongnu.org; Fri, 09 Jan 2009 10:20:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLJAF-0007mj-M0 for qemu-devel@nongnu.org; Fri, 09 Jan 2009 10:20:48 -0500 Received: from [199.232.76.173] (port=41333 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLJAF-0007mZ-GR for qemu-devel@nongnu.org; Fri, 09 Jan 2009 10:20:47 -0500 Received: from qw-out-1920.google.com ([74.125.92.146]:59555) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLJAF-0007qL-5c for qemu-devel@nongnu.org; Fri, 09 Jan 2009 10:20:47 -0500 Received: by qw-out-1920.google.com with SMTP id 5so4376060qwc.4 for ; Fri, 09 Jan 2009 07:20:46 -0800 (PST) Message-ID: <49676B43.2020406@codemonkey.ws> Date: Fri, 09 Jan 2009 09:20:35 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Ongoing changes to the displaying code References: <4966ADD4.5090102@codesourcery.com> <4966BB7A.3090303@codemonkey.ws> <4966BEC4.7080903@codemonkey.ws> <60cad3f0901090128m23977527kf658c15ba90dbaf8@mail.gmail.com> In-Reply-To: <60cad3f0901090128m23977527kf658c15ba90dbaf8@mail.gmail.com> 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 David Turner wrote: > > > I think that's a better route to go for this sort of thing. If > you think it's generally useful, I think it'd also be worthwhile > to host within the QEMU project. I just don't think it's the > right thing to add into QEMU directly. > > > For my specific needs, VNC and a separate GUI application are totally > overkill. However, it is true that QEMU itself absolutely doesn't > require to support any GUI jazz (you should probably let that to > forks/GUI wrappers instead). I would think the ability to maintain your own GUI and therefore not have to fork QEMU would outweigh the "overkill" factor. What specifically, do you consider to be overkill? Are you afraid of the performance overhead of VNC? Is the lack of VNC clients a problem (assuming you don't want a gtk dependency)? I hear a lot of people say "VNC is overkill" but practically, it seems to work pretty well for this sort of thing (as evident by virt-manager) so I'm wondering what people are concerned about. If it's performance, there are ways we can dramatically improve the performance localhost so that it should be equal to SDL. If it's the gtk dependency, then we probably look at splitting up gtk-vnc to make the gtk dependency optional and allow other display types to be easily supported. > On the other hand, it would be nice to have a slightly better way to > decouple display/events between the emulation and user-interaction > parts of the system. For example, I've attached the framebuffer > abstraction that I currently use in the Android emulator source code > (it's a well documented header file). > > It's basically a slightly better DisplayState, with explicit > producer/clients relationships and a global fifo used for > initialization/linking. I do not claim it is the absolute best way to > do it, just an example on how this can be implemented. I'd like to avoid introducing another remove communication mechanism in QEMU. VNC is extremely flexible so we should be able to do whatever we need to do with it. Regards, Anthony Liguori > If someone's interested, I can probably provide a patch against the > QEMU svn sources. > > Regards, > > - Digit > > > > Regards, > > Anthony Liguori > > Regards, > > Anthony Liguori > > > > >