Hi Keith, I have a few comments to share. > > > ❄ ❄ ❄ ❄ ❄ ❄ ❄ > > 2.3 Capabilities > > Instead of requiring all drivers to support all Present features, I've > added a set of per-CRTC capabilities. Here's the current set: > > PresentCapabilityAsync means that the target device can flip > the scanout buffer mid-frame instead of waiting for a vertical > blank interval. The precise latency between the flip request > and the actual scanout transition is not defined by this > specification, but is intended to be no more than a few > scanlines.
In the context of XWayland, we may send the buffer to the Wayland compositor (when client asks Present Option Async), instead of doing a copy. I would like the specification to be clarified to include that the buffer may be used for something else than scanout and flipping. The same comment applies for the specification of the Present options and the PresentCompleteNotify event. > > > PresentCapabilityFence means that the target device can take > advantage of SyncFences in the Present operations to improve > GPU throughput. The driver must operate correctly in the > absense of fences, but may have reduced performance. Using > fences for drivers not advertising this capability should have > no performance impact. Could you explain if this capability is linked to what you mention in PresentIdleNotify: that idle-fence could be different that none in the PresentIdleNotify event, or if this tells the client if setting a non-null fence in PresentPixmap is useful. In the latter case, if we advertise the capability, has the client the obligation to put a non-null fence in PresentPixmap and respect it? Thanks, Axel Davy _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel