[RFCv3 weston 00/15] Wayland Presentation extension
pekka.paalanen at collabora.co.uk
Thu Mar 13 06:20:36 PDT 2014
On Fri, 7 Mar 2014 14:03:48 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> Hi all,
> here is the third RFC of the Wayland Presentation protocol, now
> with a complete implementation!
> RFCv2 can be found at
> and the email thread contains extensive discussion, from which
> the conclusions have been implemented. Let me know, if I missed
> The changes to the protocol itself are listed in patch 6/15. I
> have not forgot about the new features listed in
> and I intend to write a protocol patch to get the discussion
> about those started.
> The impact to the Wayland core protocol still exists, but is
> mitigated by the fact that frame callbacks are no longer queued,
> and hence whether there is an attach or not does not affect the
> processing of frame callbacks on commit.
> Still, doing an immediate commit without a preceding
> wl_surface.attach is defined to work differently than in the
> core: the buffer state will not be applied without an attach.
> IOW, you cannot change e.g. buffer_scale without attaching a
> wl_buffer. In my opinion, the newly disabled actions did not make
> sense in the first place, but it is still a change to the core
the most important design decision I would really like to have an
explicit ACK/NAK for is the split between surface and buffer state, and
how buffer state is only applied on a commit that includes an attach.
This affects the behaviour of the core protocol on wl_surface, and also
The design of queueing in the presentation extension relies on this
split. It is fundamental in how queueing currently works.
Furthermore, if we do decide to change wl_surface.damage to use buffer
coordinates, it will have implications to queueing design, and also
be affected by the surface/buffer state split.
The most straightforward result from these both will be, that clients
cannot commit damage without an attach. That could be a problem for
"front-buffer rendering" clients, that use the same wl_buffer all the
time and just post new damage while racing with the compositor. If we
require an attach, we immediately hit the wl_buffer.release ambiguity
problem, assuming such a client ever cares about releases.
> I think we should start dicussing, how do we want the protocol
> interfaces to be designed. Do we want a global method with
> wl_surface as an argument (as in this implementation), the
> factory approach like wl_scaler/wl_viewport etc., or something
The style of the interfaces would be nice to discuss, too.
More information about the wayland-devel