Hi,
As far as the EDID is concerned, there can only be one EDID for a
display+hw pair, or the guest won't know what to do. In my use-case, I
simply pass real EDIDs through, and create a full-screen window for each
real monitor.
Ok, makes sense.
If you wanted to have two UIs displaying the same
DisplaySurface, the EDID would have to come from one of them, and the
other would have to clip, or scale.
Yes.
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?
Currently only one QemuConsole is active at a time, so that would have
to change....
That isn't mandatory any more. It is still the default behavior of a
DisplayChangeListener to follow the active_console, for compatibility
reasons. SDL and VNC still behave that way.
You can explicitly bind a DisplayChangeListener to a QemuConsole though,
by setting DisplayChangeListener->con before calling
register_displaychangelistener().
gtk binds to QemuConsole #0.
spice creates a display channel per (graphical) console. Each display
channel has a DisplayChangeListener instance, and each
DisplayChangeListener is linked to a different QemuConsole.
For your UI you probably want follow the spice model. Have a
DisplayChangeListener for each physical monitor of the host, have a
fixed QemuConsole bound to each DisplayChangeListener.
DisplayChangeListeners can come and go at runtime just fine, so you
should be able to create/destroy them on monitor plug/unplug events on
the host.