qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Multi-head support RFC


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Multi-head support RFC
Date: Wed, 06 Nov 2013 11:55:51 +0100

  Hi,

> In QEMU 1.3, there was a DisplayState list. We used one DisplayState per 
> monitor. The DisplayChangeListener has a new hw_add_display vector, so 
> that when the UI requests a second monitor the new display gets attached 
> to the emulated hardware. (patch: add_display_ptr)

I don't think we want actually add/remove stuff here.  On real hardware
your gfx card has a fixed set of display connectors, and I think we are
best of mimic that.

Support for propagating connect/disconnect events and enabling/disabling
displays needs to be added properly.  Currently qxl/spice can handle
this, but it uses a private side channel.

> A new vector, hw_store_edid, was added to DisplayState so that UIs could 
> tell emulated hardware what the EDID for a given display should be. 
> (patch: edid-vector)

Note that multiple uis can be active at the same time.
What happened with the edids then?

> VRAM size was made configurable, so that more could be allocated to 
> handle multiple high-resolution displays. (patch: variable-vram-size)

upstream stdvga has this meanwhile.

> I don't think it makes sense to have a QemuConsole per display.

Why not?  That is exactly my plan.  Just have the virtual graphic card
call graphic_console_init() multiple times, once for each display
connector it has.

Do you see fundamental issues with that approach?

> I can use a model similar to what qxl does, and put the framebuffer for 
> each display inside a single DisplaySurface allocated to be a bounding 
> rectangle around all framebuffers. This has the advantage of looking 
> like something that already exists in the tree, but has several 
> disadvantages.

Indeed.  I don't recommend that.  It is that way for several historical
reasons (one being that the code predates the qemu console cleanup in
the 1.5 devel cycle).

> Are these features something that people would want to see in the tree? 

Sure.  One of the reasons for the console cleanup was to allow proper
multihead support.

cheers,
  Gerd






reply via email to

[Prev in Thread] Current Thread [Next in Thread]