On Fri, 7 Mar 2014 14:03:48 +0200 Pekka Paalanen <ppaala...@gmail.com> wrote:
> From: Pekka Paalanen <pekka.paala...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel