[PATCH 14/19] present: Add window flip mode

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> On 2018-02-02 10:42 AM, Roman Gilg wrote:
>> It's because of what you made me aware of in the previous patch set:
>> the window original pixmap needs to have the updated content from the
>> flip Pixmap, otherwise for example screenshot applications won't work
>> anymore. I tested it with xwd.
>
> FWIW, my concerns were about using sub-surfaces in cases where the
> presented pixmap dimensions don't match the window pixmap dimensions.

And this is the main reason I didn't really worry about flipping window
pixmaps -- the application window was generally contained within a
window manager frame, which (typically) also contains window management
decorations. So the application window is generally smaller than the
frame, so the pixmap can't just be flipped. With client-side
decorations, or other techniques that make the client geometry match
that of the redirected window, figuring out how to do this makes good
sense.

>
>> I also tried to not copy, but set the window pixmap to the flip
>> pixmap. The problem I encountered here, is that the window original
>> pixmap can be controlled by the client.
>
> How?

If it's a DRM buffer passed to the server, then the client has a direct
handle to the object?

>> And when unflipping and restoring the original pixmap, this already
>> might have been deleted by the client.
>
> A pixmap is only destroyed when its refcnt member drops to 0, so that
> shouldn't be an issue.

And that also holds for the kernel objects, I assume. Is there any way
the application could do something bad with its DRM handle?

>> There might be ways to circumvent this problem, I have a few ideas,
>> but I decided to first go for a simple implementation by just copying
>> the pixmap content in order to decrease the overall complexity of the
>> patch set.
>
> I'm not sure it would significantly increase the complexity, but fair
> enough I guess.
>
> The inability to queue a presentation to the next MSC is more of a step
> back compared to the status quo.

I'm about to go write up some ideas I'm working on that will make it
possible to more regularly display redirected windows at the target MSC,
and to reliably report which MSC the window contents were displayed at.

I mention this because I think there are some parallels between that
work and this.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180202/82384a5f/attachment-0001.sig>