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

[Gerd Hoffmann <kraxel@redhat.com>]

On Do, 2013-11-07 at 09:44 +1000, Dave Airlie wrote:
> On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >   Hi,
> >
> >> It currently just adds multiple DisplaySurfaces to the QemuConsole,
> >> now Gerd said he thought I should be using multiple QemuConsoles but I
> >> really didn't think this was a good idea,
> >
> > Why?
> 
> It's a fair question and I haven't tried the other way yet and I fully
> intend to do further  investigating,
> 
> I think my main reason was the current console at least when
> interacting with gtk frontend are done on a console per tab, now if we
> have multiple outputs I would want them to be visible at the same
> time,

Sure, that needs to be addressed.  multihead is new to qemu, the ui core
can deal with it now.  There are still many rougth edges, and not all
user interfaces can deal with it, and it hasn't seen all that much
testing yet.

Current state (master / 1.7 release candidates):

 * Spice has basic support.  It opens a display channel for each
   (graphical) QemuConsole.  Sugar on top still missing.  For
   example you can't disable outputs, so the windows are always
   there, even if the guest doesn't enable & use the outputs.

 * SDL/vnc:  One window.  Ctrl-Alt-<nr> switches consoles.  Usually
   this switches between vga (grapical console 0) and text consoles
   (if present, monitor / serial / parallel at 1,2,3).  With multihead
   you'll get more graphical consoles and you can switch to them too.
   Which is obviously not what you want as you can't see all your
   heads at the same time ... 

   Your SDL2 bits address the SDL side.  vnc isn't easy to tackle,
   unlike spice it has no concept of multiple displays in the protocol,
   but given you can simply use spice instead I see little reason to
   invest much energy into extending vnc.

 * gtk: One window with (by default hidden) tabs.  First tab is the
   graphical console 0, other tabs have vte widgets for the terminals.
   Other grapical consoles are ignored.  Opening additional windows
   for them isn't hard, I even had a quick&dirty patch for that a while
   back.  I think the most tricky part here is to design a sensible user
   interface.

> now I understand we could fix this but we'd need some sort of
> console grouping to say this group of consoles represent this set of
> outputs,

qemu already links QemuConsoles to devices, you can lookup the
QemuConsole for a given device (qemu_console_lookup_by_device).  This
needs to be extended a bit to handle multiple QemuConsoles per device.
We also need to add some more metadata to the QemuConsoles and add
interfaces for the UIs to query them.

> Though further to that I'm not sure how we'd want to represent
> multiple graphic cards I assume we'd want to be able to see them all
> at once, but still have some sort of binding between separate outputs
> on one card.

UIs can decide which QemuConsoles they want display, so we can have
options to filter -- say -- by device.  Could look like this on the
command line:

qemu -device VGA,id=video0 \
     -device virtio-gpu,id=video1 \
     -vnc :0,device=video0 \
     -spice port=12345,device=video1

Today none of the UIs can have multiple instances, i.e. you can't have
one vnc server for video0 and a second vnc server for video1.  We also
don't have input routing today (i.e. send input from different UIs to
different virtual keyboards / mice), which we will need for multiseat
support in qemu.

Alot of room for improvements.  I see multiseat as long-term goal, for
now this is just something to keep in mind when coding up new stuff.  We
surely want tackle multihead first.

cheers,
  Gerd