On Wed, 25 Nov 2015 10:25:42 -0800 Jason Ekstrand <[email protected]> wrote:
> On Wed, Nov 25, 2015 at 10:15 AM, Derek Foreman <[email protected]> > wrote: > > On 13/11/15 12:21 PM, Jason Ekstrand wrote: > >> On Fri, Nov 13, 2015 at 3:18 AM, Giulio Camuffo <[email protected]> > >> 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. 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... Thanks, pq
pgpIPf3Zm_Hpz.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
