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

[Alon Levy]

On Mon, May 07, 2012 at 01:57:37PM +0200, Gerd Hoffmann wrote:
> On 05/07/12 12:28, 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.
> 
> No.  The big rectangle in the picture above (the large pixmap) has no
> surface associated with it at all.  The small "1" rectangle is the
> primary surface, rectangle "2" is the secondary head surface.
> 
> No need to copy.  But as mentioned the intersection is part of two
> surfaces now, which I'd expect to cause problems, and anything outside
> the "1" and "2" rectangles has no surface associated with it and thus
> can not be src or dst of rendering ops.

The thing is that you would still have copies, you just moved them to
the driver - since by definition the big rectangle, the screen, is
covered by the screen's pixmap, there would still be a pixmap. Maybe you
could make it so it isn't ever actually used, maybe you can even make it
zero sized, I don't know, but it's not the way it is supposed to work.

> 
> Just defining heads as a viewport to the primary surface (maybe allow
> any surface here?) should work fine.

OK, I'll go down this path then.

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