[RFCv3 weston 00/15] Wayland Presentation extension

[Pekka Paalanen]

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
> http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html
> and the email thread contains extensive discussion, from which
> the conclusions have been implemented. Let me know, if I missed
> something.
> 
> The changes to the protocol itself are listed in patch 6/15. I
> have not forgot about the new features listed in
> http://cgit.collabora.com/git/user/pq/weston.git/tree/buffer-queue3.txt?h=buffer-queue-spec
> 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
> protocol.

Hi Kristian,

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

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[1], 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[2], 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
> else?

The style of the interfaces would be nice to discuss, too.


Thanks,
pq

[1] http://lists.freedesktop.org/archives/wayland-devel/2014-February/013440.html
[2] https://bugs.freedesktop.org/show_bug.cgi?id=75303