Re: [Qemu-devel] [PATCH] Adds null check for DisplayStatus

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

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).