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

[Alon Levy]

On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > 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.
> 
> I don't think you have to copy.  You have both width and stride fields
> for surfaces.  stride doesn't need to be width * depth, you can add
> padding.  Which allows you to allocate a large pixmap in device memory,
> then create multiple surfaces which each representing parts of your
> large pixmap.

OK, sorry, this was exactly what I had in mind for the client side
implementation of QXLHead, so I should have thought of it for the
additional surfaces as well.

> 
> The approach still has its drawbacks:  Rendering ops need some extra
> math, and you can't submit rendering ops for invisible regions of your
> large pixmap.  The biggest issue are overlapping crts I suspect.  They
> would lead to overlapping surfaces.  Ouch.

I don't follow. Your suggestion if I understand is to have a new surface
generated by the driver that uses the same image with different stride,
width, and starting location (allowing it to be a rect within the
primary surfaces) compared to the primary surfaces. The only problem is
that I don't think we have any notion of shared surfaces for the client
side - so you would still need to issue every rendering op twice (or do
the copy I suggested) by the server (guest issues one draw copy, server
issues two to client)? or we will need to expand the surface creation
command to allow this relation (in which case it would be similar to
QXLHead). My suggestion of QXLHead creates a shared bitmap
surface on the client side, so doesn't have this drawback. Am I
misunderstanding you?

> 
> I guess Izik had windows guests in mind which would probably deal fine
> with the multiple surfaces approach, given that the windows monitor
> layout dialog box allows alot less to do compared to xrandr ...
> 
> cheers,
>   Gerd
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel