Second Feedback request for my GSoC project to improve Present support in Xwayland
michel at daenzer.net
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 daenzer.net> 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 daenzer.net
>>> <mailto:michel at daenzer.net>> 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
> 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 | http://www.amd.com
Libre software enthusiast | Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 224 bytes
Desc: OpenPGP digital signature
More information about the xorg-devel