Re: [Qemu-devel] console muti-head some more design input

[Gerd Hoffmann]

  Hi,

> So I felt I had a choice here for sharing a single output surface
> amongst outputs:
> 
> a) have multiple QemuConsole reference multiple DisplaySurface wihch
> reference a single pixman image,

This one.

> In either case we need to store, width/height of the console and x/y
> offset into the output surface somewhere, as the output dimensions
> will not correspond to surface dimensions or the surface dimensions
> won't correspond to the pixman image dimensions

Not needed (well, internal to virtio-gpu probably).

Just use qemu_create_displaysurface_from().  That creates a new
DisplaySurface (and pixman image) using existing backing storage.
Typically backing storage is the guests video memory.  In your case it
probably is the dma-buf the gpu rendered into (at least in the 3d case,
not sure you are there already).  You can also use normal guest ram as
backing storage (for 2d maybe?).  The framebuffer must be linear in
guest physical memory (so it is linear in host virtual too) for this to
work.

Dimensions not matching is no problem, you'll pass the scanline length
of the backing storage as linesize parameter.  Adjust the data pointer
according to x+y offset.

> So I picked (b) in my current codebase, once I untangled a few
> lifetimes issues (replace_surface - frees the displaysurface == bad,
> this is bad in general),

Why is this bad?

Some background on the design (/me feels like it would be a good idea to
brew up a docs/ui.txt from our email discussions ...):

There are basically two ways to manage the surfaces.

Case one:

   You don't have the data in a format the qemu ui code can handle.
   Such as vga text mode, or those funky planar 16 color modes.

   You'll go create a DisplaySurface for it (using
   qemu_create_displaysurface, allocating backing storage too).
   You keep it until the guest switches the video mode.  You render
   into it and you notify qemu about updates using dpy_gfx_update().

Case two:

   You have the data in a format qemu ui can handle directly.

   You'll go create a DisplaySurface using
   qemu_create_displaysurface_from, backing the DisplaySurface using
   your existing backing storage. If the viewpoint changes (panning,
   page flipping) just create a new DisplaySurface and replace the
   old one.  As the backing storage doesn't change this is cheap, so
   it is perfectly fine to do it frequently if needed.

> Another issue I had is I feel the console layer could do with some
> sort of subclassing of objects or the ability to store ui layer info
> in the console objects,

You can do that by embedding the DisplayChangeListener into your ui
state struct.  Spice does it this way:

State struct for one display channel:

   struct SimpleSpiceDisplay {
      [ ... ]
      DisplayChangeListener dcl;
      [ ... ]
   };

When registering it binds the spice channel / display listener to a
console (i.e. don't follow active_console):

   ssd->dcl.ops = &display_listener_ops;
   ssd->dcl.con = con;
   register_displaychangelistener(&ssd->dcl);

Then in the callbacks go find the spice display channel state:

   SimpleSpiceDisplay *ssd = container_of(dcl, SimpleSpiceDisplay, dcl);

As there is a fixed relationship between QemuConsole and
DisplayChangeListener you can store all the data you need to manage the
QemuConsole there.

cheers,
  Gerd