[Qemu-devel] Multi-head support RFC

[John Baboval]

Hello,

I am currently the device model maintainer for XenClient Enterprise. As 
you may or may not know, we maintain a patch queue on top of QEMU 
(currently 1.3) that adds functionality needed to support XCE features.

One of the major things we add is robust multi-head support. This 
includes DDC emulation for EDID data, variable VRAM size, monitor 
hot-plug support, simulated VSYNC, and guest controlled display 
orientation. This includes both the necessary interfaces between the hw 
and ui, and a new emulated adapter (with drivers) that exercises the 
interfaces.

Between QEMU 1.3 and QEMU 1.6, a lot of changes were made to the 
QemuConsole and DisplayState structures that will require significant 
changes to our patches. I'd like to adapt to these changes in such a way 
that they might make some of our work acceptable upstream. As such, I'd 
like to describe how the patches currently work, describe how I'd 
propose they work in the new version, and solicit feedback as to if the 
plans would be acceptable.

I've stuck our current patch queue on github for convenience. If I refer 
to a patch in the below description, you can check it out there: 
https://github.com/jbaboval/xce-qemu.pq

This is what we currently do:

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)

Each DisplayState was given an ID, so that emulated hardware could keep 
track of which EDID and other metadata went with with DisplayState. 
(patch: display-id-allocation)

A new function, gui_start_updates, starts refresh of the new display. 
This seems to be equivalent to the new gui_setup_refresh() that exists 
in newer versions. (patch: gui_start_updates)

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)

A new vector, hw_notify, was added to DisplayState so the UIs could tell 
the emulated hardware about interesting events, such as monitor hotplugs 
(new windows), orientation changes, availability of hardware cursor 
functionality, etc... (patch: display-hw-notify)

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


The flow is:

- The user requests a hotplug (user added a "monitor" with a menu, UI 
reacted to a udev hotplug or XRandR event, or whatever)
- The UI asks the hw to allocate a new display. If the hw doesn't 
support it (vector is NULL), the system continues with one display.
- The hw returns a new DisplayState to the UI with all the hw_ vectors 
filled in
- The UI registers its DisplayChangeListener with the new DisplayState
- The UI provides an EDID for the new display with hw_store_edid()
- The UI notifies the guest that an event has occured with hw_notify()
- The UI starts a gui timer for the new DisplayState with 
gui_start_updates()
- The guest driver does its normal thing, sets the mode on the new 
display, and starts rendering
- The timer handler calls gfx_hw_update for the DisplayState
- The hw calls dpy_update for changes on the new DisplayState

.....


In the latest code, DisplayState isn't a list anymore, and many 
operations that apply to a DisplayState apply to a QemuConsole instead. 
Also, the DisplaySurface is a property of the QemuConsole now instead of 
part of the DisplayState. I'm going to have to make some fairly 
fundamental changes to our current architecture to adapt to the latest 
upstream changes, and I would appreciate feedback on the options.

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

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. It was convenient - but not necessary - to have a 
DisplaySurface per display, since that kept track of the display mode, 
allowed different depths per monitor (not very useful, but possible), 
etc. If the displays are different resolutions, it leaves a dead space 
of wasted memory inside the region. If there's a single DisplaySurface, 
some other structure/list/array will need to be added to track the 
individual resolutions, offsets, and strides of the sub-regions in order 
to be able to display them in separate windows or - more likely - as 
full screen on real displays. It also makes hot-plugging more complex, 
since adding/removing a display will alter the configuration of the 
existing displays.

I could turn the DisplayState and DisplaySurface in QEMU console into 
lists, and run much like my existing patches.

I could move the DisplaySurface back into DisplayState and have one 
list... (major downside: I'd have to fix every hw and ui, also it must 
have been moved out of there for a reason)

Moving my new vectors into the nicely cleaned up 
DisplayChangeListenerOps and GraphicsHardwareOps structures seems like a 
no-brainer.

......


I'm flexible on how to implement this stuff if it means it gets done in 
a way that could be pushed. Ideally I'd like to be able to re-use as 
much of the code I already have as possible. But really I can re-do all 
of it as long as the end result is acceptable upstream and meets my list 
of feature requirements. Which is: Hot-plugging displays, ability to 
pass EDIDs, variable VRAM size.

Are these features something that people would want to see in the tree? 
If so, I'd appreciate input so I can be working towards something 
acceptable to as many people as possible.