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

[Michel Dänzer]

On 2018-02-02 12:08 PM, Michel Dänzer wrote:
> On 2018-02-02 10:42 AM, Roman Gilg wrote:
> 
>> 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?
> 
> 
>> 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.

Taking a step back, do we even need to keep around the original pixmap
and unflip to it at all? I had a chat on IRC about this with Keith a
while ago, see the attached log excerpt.

Keith's main concern is that the presenting client could be able to
read/write the window pixmap's contents behind the X server's back. I
understand this concern at least somewhat in the case of per-screen
flips, because the screen pixmap can be used for completely different
windows after flipping.

But this seems irrelevant for per-window flips. In this case, the window
pixmap isn't used for anything else after flipping, so having direct
access to the pixmap doesn't allow the client to do anything it couldn't
do anyway using the X11 protocol. (There might be exceptions to this if
the window wasn't created by the presenting client, and the Security
extension comes into play. But that would be a rather exotic scenario,
so I don't think we need to consider it here.)


>> 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.

Unfortunately, I've come to realize that this doesn't work correctly in
all cases. Consider this scenario:

A client does one or more presentations to a window, which can be
executed as a flip. At some point it stops doing presentations, and
instead uses other X11 requests to update the window contents.

With the implementation in this patch, the latter updates will only
affect the original window pixmap, not the flip pixmap, so they won't be
visible to the Wayland compositor and its output (until an unflip to the
original window pixmap is triggered for some reason).

To avoid this, the flip pixmap must be set as the window pixmap, as is
done for per-screen flips.

Assuming the original window pixmap doesn't need to be saved and
restored, this should result in even less complexity than in this patch.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorg-devel.log
Type: text/x-log
Size: 4105 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180202/61372a6c/attachment.bin>