[PATCH wayland] client: add wl_proxy_get_version function

[Jason Ekstrand]

On Oct 6, 2014 12:45 AM, "Pekka Paalanen" <ppaalanen at gmail.com> wrote:
>
> 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'...

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

>
> > (...)
> > >
> > >
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141006/e6dce6ef/attachment-0001.html>