On Oct 6, 2014 12:45 AM, "Pekka Paalanen" <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > > Re-adding CCs and some more... > > On Mon, 06 Oct 2014 09:17:41 +0300 > Rémi Denis-Courmont <<a href="mailto:remi@remlab.net">remi@remlab.net</a>> wrote: > > > Hello, > > > > Le 2014-10-06 03:29, Jason Ekstrand a écrit : > > > Remi, > > > While this would probably be nice, your approach isnt going to work. > > > > Yeah, I figured that much after I submitted the patch. And then I > > rediscovered that the client library does not actually know the version > > of the project objects, and wl_registry_bind() cannot be modified > > without breaking backward compatibility. > > > > But now, I am even wondering whether this makes any sense. Assuming > > wl_proxy_get_version() gets implemented "somehow", what should the > > library do if the proxy version is *higher* than version the library > > knows of? Say a new version Y of an interface FOO adds a new request and > > a new event compared to older version X. If a FOO object is instantiated > > with version Y but the new request is never used and there is no event > > handler for the new event, will it still work as with version X? I guess > > not :-( > > If there is no event handler set, the client will abort/crash if the > event is ever sent. > > > In my specific case, can the Wayland client treat a wl_surface version > > 4 or higher as a wl_surface version 3? If not, I cannot rely on > > 'wl_proxy_get_version(surface) >= 2'... You have to do some sort of negotiation between The client and the library. If you have the get_version stuff you can enforce it somewhat by giving the client an error if it goes too high. > > Changing the semantics[5] of wl_surface.damage is a good example where > this would fail indeed. If a library only knows up to version 3, but > the app gives it a wl_surface of version 4, the damage coordinates > would be wrong. > > Originally we had the idea, that all version bumps are backwards > compatible. Simply testing for version >= X would always work. The > wl_surface.damage change is not backwards compatible in that sense. > > Looks to me like if we don't fix damage, then this versioning problem > would be solvable... :-( I'll respond to that on the bug. I don't want to side-track this conversation with damage. > > > Also somewhat related to this question, what happens (or should happen) > > if a Wayland client binds a version supported by the display server, but > > not supported by the client's protocol bindings? That would happen if > > the client blindly copies the version from wl_registry.global to > > wl_registry.bind. > > Such blind copy is a bug: a client will always need some code changes > to support new features added to an interface, so it always needs to > bind with MIN(advertized, my_supported). And my_supported cannot be > higher than the available XML definition during client build. But here > is a problem with client-side libraries: my_supported cannot be higher > than the supported version in any used library, if not all protocol > version bumps are backward compatible. > > And even then, I can imagine a case where it would still fail: app > creates version 5 of a global, hands the global to a library that only > knows up to version 4. The library creates a new object with the > version 4 interface, automatically gets version *5* new object, the new > object delivers an event added in version 5, kaboom. > > A compositor does not advertise a version that libwayland-server does > not support, but that includes the assumption that both server and > client use the same libwayland version... which might not be true. > > And it's not really remedied by adding new protocols as XML-only into > libwayland, either. Such protocols would simply be built in to the > users, i.e. the client apps and libraries, which brings a problem if a > library is built with version lower than what the app uses. > > Oh dear... :-/ > > I'm not sure there is any way around *bidirectional* explicit version > negotiation between an app the libraries it uses. Bidirectional means > that the library tells the max versions it can support and the app > needs to obey that, and any objects the app passes to the library needs > to pass the version, too. Well, the latter case might be able to be > automated via wl_proxy_get_version(), but not the former AFAICS. Yes, I don't think we can get around that. --Jason > > > (...) > > > > > > <a href="http://lists.freedesktop.org/archives/wayland-devel/2014-April/014004.html">http://lists.freedesktop.org/archives/wayland-devel/2014-April/014004.html</a> > > > [4] > > > > I see, thanks. > > > > Thanks, > pq > > > [5] <a href="https://bugs.freedesktop.org/show_bug.cgi?id=78190">https://bugs.freedesktop.org/show_bug.cgi?id=78190</a>