On Dec 7, 2015 7:20 AM, "Pekka Paalanen" <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > > On Wed, 25 Nov 2015 10:25:42 -0800 > Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > > > On Wed, Nov 25, 2015 at 10:15 AM, Derek Foreman <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote: > > > On 13/11/15 12:21 PM, Jason Ekstrand wrote: > > >> On Fri, Nov 13, 2015 at 3:18 AM, Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> 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