Le 2014-10-06 11:26, Pekka Paalanen a écrit :
> 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... :-(
Oh I'm being silly, we only need to fix damage in a backward
compatible
way: add a new request, don't modify the behaviour of the old one.
Keeping backward compatibility wrt. version >= X checks seems like a
good idea and should reduce the problem set somewhat.
You could stick to adding new requests rather than redefine existing
ones.
But what about events. AFAICT, they would still require either:
- never adding events in new versions,
or
- adding events that only fire after a new requests was sent,
and
- never copying the listener structure ever in the client library
(to prevent out-of-bounds read).
Otherwise, it would still fail the code path setting the object
listener targets an older interface version than the code path creating
the object.
--
Rémi Denis-Courmont
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
