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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel