From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPJeZ-0004hH-0F for qemu-devel@nongnu.org; Tue, 20 Jan 2009 11:40:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPJeX-0004ei-8u for qemu-devel@nongnu.org; Tue, 20 Jan 2009 11:40:38 -0500 Received: from [199.232.76.173] (port=57685 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPJeW-0004eF-Vk for qemu-devel@nongnu.org; Tue, 20 Jan 2009 11:40:37 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:4009) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPJeW-0006xf-Iw for qemu-devel@nongnu.org; Tue, 20 Jan 2009 11:40:36 -0500 Message-ID: <4975FDA0.8070901@eu.citrix.com> Date: Tue, 20 Jan 2009 16:36:48 +0000 From: Stefano Stabellini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Adds null check for DisplayStatus References: <4973267B.9010901@juno.dti.ne.jp> <49734152.7080302@juno.dti.ne.jp> <49746680.3070400@eu.citrix.com> <49749B91.6080200@juno.dti.ne.jp> <49749CB7.1020508@eu.citrix.com> <4974A593.1020607@codemonkey.ws> <4974A802.7080506@eu.citrix.com> <4974CF8B.5080409@codemonkey.ws> <4975AD3E.8050101@eu.citrix.com> <4975F42B.7080904@redhat.com> In-Reply-To: <4975F42B.7080904@redhat.com> Content-Type: text/plain; charset=UTF-8 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 Gerd Hoffmann wrote: > Stefano Stabellini wrote: >> Allocate a DisplaySurface in dumb_display_init if none else does it. >> The DisplaySurface will be used for the qemu monitor, serial and >> parallel ports, etc. > > Ah. That one should fix the "-vga none -vnc :0" crashes, right? Yes. > Some more displaystate questions: > > I'm sitting here with a initialization order issue I'm not sure how to > tackle best. xenfb calls graphics_console_init() once the frontend and > backend finished the handshake, usually a few seconds after the guest > started running. In case the guest has no framebuffer frontend driver > the graphics_console_init() call doesn't happen at all. So it behaves > like a hot-plugged graphics card. > > With the new displaystate allocation rules and dumb_display_init() in > place I will end up with *two* displaystates in case I keep the setup > logic this way. Is that going to work? There is a new > register_displaystate() which maintains a linked list of displaystates, > so it looks like it might work? Or is this work in progress? > > What do you suggest to do? What other patches do you have in the queue > I maybe should know about when adapting xenfb? Will the text consoles > (monitor, serial line, ...) continue to hitchhike on the displaystate of > the graphics display? > The goal is to have each text console on a different displaystate, but I don't have any patch to accomplish this at the moment. In your case the problem happens when you have to call graphics_console_init() after dumb_display_init(): currently two DisplayState are not going to work properly (they could work if you manually hook the new DisplayState to another Sdl on Vnc server but certainly not on the same one). There are many workarounds to this issue, none of them particularly pretty. Probably the best thing you could do at the moment is calling graphic_console_init() in any case in xenfb_new whether you are going to use it or not (that is more or less the same thing that dumb_display_init does).