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

[Gerd Hoffmann]

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.

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

cheers,
  Gerd