Second Feedback request for my GSoC project to improve Present support in Xwayland

Michel Dänzer michel at
Mon Aug 14 07:32:37 UTC 2017

On 11/08/17 12:04 AM, Pekka Paalanen wrote:
> On Mon, 7 Aug 2017 17:36:27 +0900
> Michel Dänzer <michel at> wrote:
>> On 04/08/17 06:57 PM, Roman Gilg wrote:
>>> On Fri, Aug 4, 2017 at 8:44 AM, Michel Dänzer <michel at
>>> <mailto:michel at>> wrote:
>>>     On 03/08/17 09:11 PM, Roman Gilg wrote:  
>>>     > Also there is the following issue, which I encountered: The Present
>>>     > extension assumes, that on flip the DDX is not able to flip immediately,
>>>     > but signals present_even_notify for the flip a little bit later (this
>>>     > doesn't mean that's not async, just that the flip is pending for a
>>>     > little while). But in the Xwayland  case (or maybe other DDX), we can
>>>     > and want flip immediately.  
>>>     Then you can call present_event_notify immediately. :)
>>> The problem I faced when doing that, was that present_event_notify
>>> directly does some changes to the current and pending flips, while the
>>> present_execute routine assumes that these changes are not yet done.
>>> For example vblank->pixmap gets nulled on present_event_notify here:
>>> But it's still needed after the flip here:
>>> While I tried in the beginning to simply guard against these changes
>>> individually, for example by setting a local variable vblank_pixmap =
>>> vblank->pixmap in present_execute and then working with the local
>>> variable, I felt that the more clean and secure version is to introduce
>>> the additional hook for DDX' with immediate flips.  
>> Is there such a thing as an "immediate flip" though? All you can do in
>> the flip hook is send the "flip" request to the Wayland compositor,
>> right? The intent of the current interface is that the driver only calls
>> present_event_notify once it receives confirmation that the flip has
>> completed. Are there no appropriate Wayland events that can be used for
>> this?
> Hi,
> depends on what you consider as "flip complete".
> If it is enough that the Wayland server has processed the attach/commit
> and any side-effects that might cause, including a possible release of
> a previous buffer, then you can use wl_display.sync request. When the
> callback it creates sends an event, the Wayland server has processed
> all requests you sent before the wl_display.sync. This is as immediate
> as it can be.

This sounds like it would be useful for the PresentOptionAsync case.

> If "flip complete" means the buffer has actually hit the screen, then
> there is the Wayland Presentation feedback extension that gives you
> exactly that.

That should be what we want in the normal case without PresentOptionAsync.

Earthling Michel Dänzer               |     
Libre software enthusiast             |             Mesa and X developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 224 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the xorg-devel mailing list