[PATCH wayland] client: add wl_proxy_get_version function

[Pekka Paalanen]

Re-adding CCs and some more...

On Mon, 06 Oct 2014 09:17:41 +0300
Rémi Denis-Courmont <remi at remlab.net> 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