Re-adding CCs and some more... On Mon, 06 Oct 2014 09:17:41 +0300 Rémi Denis-Courmont <[email protected]> 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'... 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... :-( > 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. > (...) > > > > http://lists.freedesktop.org/archives/wayland-devel/2014-April/014004.html > > [4] > > I see, thanks. > Thanks, pq [5] https://bugs.freedesktop.org/show_bug.cgi?id=78190 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
