On ons, 2013-05-22 at 20:57 -0400, Kristian Høgsberg wrote:
> * Don't send out new wl_output events to clients that bind with
> version 1. For this I think we want to extend wl_resource with an
> int version; field.
Somewhat related, and I mentioned this earlier in the thread, we have a
problem with versioning of the *server* too. For instance, if you build
the new wayland server libs and run the old weston on it then you will
get server crashes if some client uses the new wayland ops.
It happens this way:
The old weston client did:
wl_client_add_resource(client, &surface->resource);
However, here resource.object.interface points to wl_surface_interface,
which is:
extern const struct wl_interface wl_surface_interface;
So, the wl_surface_interface is not in the client, but rather in
libwayland-server, as:
WL_EXPORT const struct wl_interface wl_surface_interface = {
"wl_surface", 3,
9, wl_surface_requests,
2, wl_surface_events,
};
This here hardcodes the version (3) into the *server* library rather
than the compositor, so when the compositor is later run with a newer
server library the request dispatcher assumes that the compositor
handles surface version 3, which means it will accept the new requests
and call into the vfunc in the compositor. But that vfunc doesn't
contain the new request, so we call into hyperspace and crash.
Similar things happens in the client if the compositor sends an event
that is later than the version the client bound as. This is clearly a
bug in the compositor though, so its not really as important.
I see two possibilities here. Either we add a version to
wl_client_add_resource() and encode version information into
wl_surface_requests. Then the dispatch machinery can check the version
and only dispatch the right requests. Or we could set up the headers so
that each compositor gets the wl_surface_interface linked into the
compositor itself. Of course, the second version has a similar behavior
to the current in the sense that if you accidentally rebuild the old
weston against the new wayland library you'd still get the crash, so the
first version seems more correct.
I'll have a look at this.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
