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

[Alon Levy]

On Mon, May 07, 2012 at 01:28:58PM +0300, Alon Levy wrote:
> 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 ...

Forgot to mention, from reading the WDDM related docs (Video
Presentation Network is the umbrella term, they have sources and
targets, respectively crtc and output in RANDR speak), it isn't clear if
there can be a different surface for each source, but it is definitely a
surface, so just extending QXLHead with a surface id (and the flags
field Hans suggested can't hurt) would probably work. Or take your
suggestion (the way I understand it) and add flags to the same effect to
the SurfaceCreate message.

> > 
> > cheers,
> >   Gerd
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel