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

[John Baboval <baboval@spineless.org>]

I've dug into this further, and basically gotten what I had before 
working against the latest code. So now the ugly bits are making 
themselves known.

In my existing patch set, dpy_refresh is called for each display, 
however since hw_update takes an opaque pointer to the hw info 
structure, it has to be called per-hw, not per-display. So the ui's 
dpy_refresh implementation calls hw_update only for the first display, 
and the hw updates all displays each time it is called. Not only is this 
ugly, but it requires a mechanism to loop through all the consoles in 
the hw code, which can't be done without breaking all the nice 
protections that have been set up between the ui and hw.

The lack of a per-display hook in the HwOps calls is cumbersome in other 
places too. For example in the hook I'm adding for store_edid, the EDID 
needs to be for a specific console, so I have to pass an index.

I think it would be better if the HwOps calls all took a QemuConsole 
instead of the opaque structure. The hw implementations can dig their 
opaque structure out from there. (Of course I'd have to go update all 
the emulated cards to handle the new model... But that's the price of 
progress I suppose.) I'd love you're opinion on the matter before I 
spend the time making the changes though...

On 11/7/2013 10:54 AM, John Baboval wrote:
> On 11/7/2013 8:46 AM, Gerd Hoffmann wrote:
>>    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.
>
> I think the best thing for me to do at this point is to just start 
> implementing with multiple QemuConsole, then, and post again when I 
> have a better idea of what it ends up looking like. I'll keep you posted.
>
>>
>> cheers,
>>    Gerd
>>
>>
>