[RFC wayland] Track protocol object versions inside wl_proxy.

[Jason Ekstrand]

On Dec 7, 2015 7:20 AM, "Pekka Paalanen" <ppaalanen at gmail.com> wrote:
>
> On Wed, 25 Nov 2015 10:25:42 -0800
> Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> > On Wed, Nov 25, 2015 at 10:15 AM, Derek Foreman <derekf at osg.samsung.com>
wrote:
> > > On 13/11/15 12:21 PM, Jason Ekstrand wrote:
> > >> On Fri, Nov 13, 2015 at 3:18 AM, Giulio Camuffo <
giuliocamuffo at gmail.com> wrote:
> > >>> So do i understand correctly that if the app creating the
> > >>> wl_compositor was built against a libwayland without this patch the
> > >>> version returned in mesa by wl_proxy_get_version() for every proxy
> > >>> will be always 1?
> > >>
> > >> Yes, see also the second e-mail link below.  I proposed to make
> > >> wl_display version 0 so that libraries can detect whether the client
> > >> was built against old or new libwayland.
> > >>
> > >> --Jason
> > >
> > > But the generated protocol headers won't have wl_surface_get_version()
> > > in that case, so build would fail?
> > >
> > > I'm finally trying to build a client that shows this failure mode, and
> > > it's starting to feel quite contrived...
> >
> > The issue that arises is if you have a client built against an old
> > version of libwayland that uses a library built against a newer
> > version.  Let's make this extremely concrete:
> >
> > Suppose that we use this wl_surface_get_version() in mesa's EGL
> > implementation to determine whether or not we have a buffer_damage
> > request.  We do that, merge it into mesa master, and start shipping it
> > in distros.  Then some old client comes along that was built against
> > libwayland 1.3.  It can run against libwayland 1.7 just fine because
> > everything's backwards compaible.  It can also run against our
> > brand-new mesa because the GL and EGL apis are backwards compatible.
> > However, whatever wayland objects it passes in to EGL will be created
> > using the old api that doesn't have _versioned functions.  The result
> > of this is that all objects appear to be version 1 because that's what
> > wl_display starts at.
> >
> > This is ok for buffer_damage() because that's just adding a request.
> > However, if there's something more subtle that happens when an object
> > changes version such that treating a version 3 object as a version 1
> > object may not always be correct, then we have a problem.  While, in
> > general, we should try to avoid these kinds of changes, they can
> > happen so we should let the user of wl_proxy_get_version() be able to
> > distinguish between version 1 and "I don't know".
>
> Hi,
>
> FYI, I've been thinking about this small detail. Binding an object with
> version 3, and then using it like you'd use version 1 object is
> something we do all the time everywhere without even realizing. I don't
> think we can or should ever break that compatibility - nowdays I think
> it is part of the protocol stability promise.
>
> I think this is also part of the reason we started to favour adding a
> new request rather than making the semantics of an existing one
> version-dependent.
>
> This is not a comment against the "unversioned version" concept at all,
> it is a rule I believe we should follow in protocol design. However, I
> bet someone eventually manages to create a mess where changing
> behaviour by version becomes the only solution, so "unversioned
> version" will probably become useful. But it should be a last resort.

I agree. I wasn't claiming that we should actively do that, but that the
wl_proxy API should plan for that contingency.

Even in the current example, we could take advantage of it.  A
SwapBuffersWithDamage implementation can do actual damage for wl_surface
version 1 but not later versions because they may have rotation.  (OK,
maybe not because you could crop/scale a version 1 surface, but I think you
see what I mean).

> Re: versioning wl_display itself, I agree with Jason that it doesn't
> matter: wl_display cannot really be extended anyway. We have no way to
> negotiate a new version for it - libwayland-client would need to
> internally create a wl_registry, fish out a new wl_display global, bind
> it with a new version, and then replace the old object with it somehow.
> I shudder to think of a situation where this would be necessary...

And if they do, then the new wl_display will get created with
constructor_versioned and get the correct non-zero version number.
However, that would also cause everything that gets created with said
wl_display to also have at least version n.  Maybe better to just
special-case wl_display...

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151207/bdeef423/attachment.html>