[Spice-devel] [protocol RFC 0/2] RANDR support via QXLHead + SpiceHead

[Alon Levy]

On Mon, May 07, 2012 at 09:03:02AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >  1. Guest enables a new monitor:
> >  2. Guest pushes QXLHead command to command ring
> >  3. Server sends SpiceHead message on the ring's display channel.
> >  4. Client creates a window out of [x, y, width, height] scanning out of the primary surface (there is one associated primary with the display channel)
> 
> Iziks original idea for that one was to just use additional surfaces for
> the additional heads.  QXL_IO_{CREATE,DESTROY}_PRIMARY write an id
> because of that, which is forced to be zero right now.  IIRC the plan
> was to just allow non-zero values for more heads there, so each
> display/head has its own primary surface.

But there is no concept of an additional surface in the guest driver.
RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per
CRTC pixmaps) has a single screen wide pixmap. A screen is one per X
server, so there is just one even if you have multiple heads. And the
CRTCs scan out of it. To copy the RANDR docs diagram (removed the double
output):


       ┌─────────────────────────────────┐
    ┏━━━━━━━┳───────────────┐       ╔════════╗
    ┃   1   ┃               │       ║   A    ║
    ┃   ┏━━━╋━━━━━━━━━━━━━━━┫       ║        ║
    ┣━━━╋━━━┛               ┃       ╚════════╝
    │   ┃         2         ┃─────────────────┐
    │   ┃                   ┃        ╔═══════════════════╗
    │   ┃                   ┃        ║                   ║
    │   ┗━━━━━━━━━━━━━━━━━━━┫        ║        B          ║
    └───────────────────────┘        ║                   ║
    ┌──────┐  ┏━━━━┓  ╔══════╗       ║                   ║
    │screen│  ┃CRTC┃  ║output║       ╚═══════════════════╝
    └──────┘  ┗━━━━┛  ╚══════╝

So if we were to create an additional surface we will have to issue copy
commands for it from the primary surface. While possible, I don't see
how that is simpler then the proposal I gave, quite the opposite.
Another option is to have a new surface that is implicitly a copy of a
part of an existing surface - which is just another way of stating what
I proposed.

> 
> One obvious issue with that is that the QXLDevSurfaceCreate struct lacks
> an field to pass on the surface id.
> 
> A possible alternative approach is to just use a normal SurfaceCmd and
> use a flag to indicate that this specific surface is supposed to be a
> new head.
> 
> > Some other notes:
> >  a. To disable a monitor, send (id, 0, 0, 0, 0) (So there remain invalid range of
> >  values {(id, x, y, width, height) | max(x, y, width, height)!=0 and min(width,
> >  height) = 0})
> 
> Would be a simple surface destroy in that case.
> 

I understand that using the existing commands removes the need to change
the protocol, but in this case it looks like abusing the commands - a
surface is a general purpose rendering target / source, and a head is
just a clone of a subrect of an existing primary surface.

> cheers,
>   Gerd