Re: Protocol backwards compatibility requirements?
On Mon, Apr 20, 2020 at 03:05:32PM +0300, Pekka Paalanen wrote: > On Thu, 16 Apr 2020 17:47:56 +1000 > Christopher James Halse Rogers wrote: > > > On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > > > Hi, > > > > > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > > > wrote: > > >> Hi all, > > >> > > >> This is request for comments on the exact requirements for protocol > > >> backwards compatibility for clients binding to new versions of an > > >> interface. > > >> Reason for this are the high-resolution wheel scrolling patches: > > >> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 > > >> > > >> Specifically, the question is: do we **change** protocol elements or > > >> behaviour as the interface versions increase? A few random examples: > > > > > > What we can't do is: > > > > > > - Change existing messages' signature > > > - Completely remove a message > > Indeed. > > > > > It should be relatively easy to modify wayland-scanner to support both > > of these things, *if* we decide that it's a reasonable thing to do. > > (You'd do something like add support for > removed_in="5"/> and the like) > > How would that work, given the version is negotiated at runtime? > > The message signature structs are now ABI as well, and we have no room > for alternate signatures, do we? > > > > > > >> - event wl_foo.bar introduced in version N sends a wl_fixed in > > >>surface coordinates. version N+1 changes this to a normalized > > >>[-1, +1] range. > > > > > > Argument types can't be changed. This would be a breaking change for > > > the > > > generated code, we can't do that. > > > > But this isn't changing the argument type; it's changing the > > interpretation of the argument. > > In both cases the type is wl_fixed; in the first you interpret this > > wl_fixed as being in surface coordinates, in the second you interpret > > it differently. > > > > This doesn't require any changes to code generation; I don't think this > > is (in principle) any more disruptive than changing “wl_foo.baz is > > sent exactly once” to “wl_foo.baz is sent zero or more times”, > > which you're happy with. > > Something we rarely consider is if you pass Wayland protocol objects > into a library without negotiating the object version with the library > first. For example, we pass wl_surface into the EGL Wayland wrapper > library. If wl_surface would get a version bump breaking backwards > compatibility, meaning that version N+1 changes something that existed > in version N, the library handling only version N would fall apart. ftr, this seems like something that should be noted in the protocol's xml directly to avoid future accidents. > I sincerely hope this is the only case of a library taking a ready-made > Wayland object in. Getting the version negotiation right needs > inconvenient additions to the library API that I don't think many would > bother or even realize it's needed. > > You can query the version of a wl_proxy, sure, but that does not help > you if it returns a number larger than what your code knows about. > > Btw. this is also a problem in the opposite direction. Let's say you > use a toolkit and the toolkit allows you access to the Wayland protocol > objects. Then the toolkit gains support for new interface versions and > uses them, but your app code is not updated. If the protocol change is > backwards incompatible, your app code may break even if only behaviour > changes and not signatures. > > > >> - request wl_foo.bar introduced in version N takes an int. version > > >> N+1 > > >>changes wl_foo.bar to take a wl_fixed and an enum. > > > > > > Ditto. > > > > > >> - request wl_foo.bar introduced in version N guaranteed to generate > > >> a single > > >>event wl_foo.baz. if the client binds to version N+1 that event > > >> may be > > >>sent zero, one or multiple times. > > > > > > This is fine. > > > > > >> I think these examples cover a wide-enough range of the possible > > >> changes. > > >> > > >> My assumption was that we only ever add new requests/events but > > >> never change > > >> existing behaviour. So wl_foo.bar introduced in version N will > > >> always have > > >> the same behaviour for any interface N+m. > > > > > > We can change existing requests' behaviour. This has already been > > > done a > > > number of times, see e.g. wl_data_offer.accept or > > > xdg_output.description. > > > > > > Clients should always have a max-version, ie. they should never > > > blindly bind > > > to the compositor's version. > > > > > > What is also fine is marking a message as "deprecated from version > > > N". Such a > > > message wouldn't be sent anymore starting from this version. > > > > > >> I've seen some pushback for above linked patchset because it gets > > >> complicated and suggestions to just change the current interface. > > >> The obvious advantage is being able to
Re: Protocol backwards compatibility requirements?
On Mon, Apr 20, 2020 at 15:05, Pekka Paalanen wrote: On Thu, 16 Apr 2020 17:47:56 +1000 Christopher James Halse Rogers wrote: On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > Hi, > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > wrote: >> Hi all, >> >> This is request for comments on the exact requirements for protocol >> backwards compatibility for clients binding to new versions of an >> interface. >> Reason for this are the high-resolution wheel scrolling patches: >> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 >> >> Specifically, the question is: do we **change** protocol elements or >> behaviour as the interface versions increase? A few random examples: > > What we can't do is: > > - Change existing messages' signature > - Completely remove a message Indeed. It should be relatively easy to modify wayland-scanner to support both of these things, *if* we decide that it's a reasonable thing to do. (You'd do something like add support for and the like) How would that work, given the version is negotiated at runtime? The message signature structs are now ABI as well, and we have no room for alternate signatures, do we? Sure we do. Internally we can just give them different names, with different contents, and switch based on the version requested at runtime. From the client API side it's more difficult (at least for requests), because we can't remove any symbols - we *can* make it a client error with a good error message, though. On the events side it's easier, as we can add a wl_foo_listener_v5 struct and wl_foo_add_listener_v5. This does add a new sharp edge to the raw wl_proxy_* interface, but client code isn't expected to be using that and this doesn't seem particularly hard for language bindings to adapt to. > >> - event wl_foo.bar introduced in version N sends a wl_fixed in >>surface coordinates. version N+1 changes this to a normalized >>[-1, +1] range. > > Argument types can't be changed. This would be a breaking change for > the > generated code, we can't do that. But this isn't changing the argument type; it's changing the interpretation of the argument. In both cases the type is wl_fixed; in the first you interpret this wl_fixed as being in surface coordinates, in the second you interpret it differently. This doesn't require any changes to code generation; I don't think this is (in principle) any more disruptive than changing “wl_foo.baz is sent exactly once” to “wl_foo.baz is sent zero or more times”, which you're happy with. Something we rarely consider is if you pass Wayland protocol objects into a library without negotiating the object version with the library first. For example, we pass wl_surface into the EGL Wayland wrapper library. If wl_surface would get a version bump breaking backwards compatibility, meaning that version N+1 changes something that existed in version N, the library handling only version N would fall apart. I sincerely hope this is the only case of a library taking a ready-made Wayland object in. Getting the version negotiation right needs inconvenient additions to the library API that I don't think many would bother or even realize it's needed. You can query the version of a wl_proxy, sure, but that does not help you if it returns a number larger than what your code knows about. Btw. this is also a problem in the opposite direction. Let's say you use a toolkit and the toolkit allows you access to the Wayland protocol objects. Then the toolkit gains support for new interface versions and uses them, but your app code is not updated. If the protocol change is backwards incompatible, your app code may break even if only behaviour changes and not signatures. This is an additional cost that should be considered for types that may be transferred across library boundaries like this; we should also try to make it clear to toolkits that this is a fraught API. >> - request wl_foo.bar introduced in version N takes an int. version >> N+1 >>changes wl_foo.bar to take a wl_fixed and an enum. > > Ditto. > >> - request wl_foo.bar introduced in version N guaranteed to generate >> a single >>event wl_foo.baz. if the client binds to version N+1 that event >> may be >>sent zero, one or multiple times. > > This is fine. > >> I think these examples cover a wide-enough range of the possible >> changes. >> >> My assumption was that we only ever add new requests/events but >> never change >> existing behaviour. So wl_foo.bar introduced in version N will >> always have >> the same behaviour for any interface N+m. > > We can change existing requests' behaviour. This has already been > done a > number of times, see e.g. wl_data_offer.accept or > xdg_output.description. > > Clients should always have a max-version, ie. they should never > blindly bind > to the compositor's
Re: Protocol backwards compatibility requirements?
On Mon, 2020-04-20 at 15:05 +0300, Pekka Paalanen wrote: > On Thu, 16 Apr 2020 17:47:56 +1000 > Christopher James Halse Rogers wrote: > > > On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > > > Hi, > > > > > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > > > wrote: > > > > Hi all, > > > > > > > > This is request for comments on the exact requirements for protocol > > > > backwards compatibility for clients binding to new versions of an > > > > interface. > > > > Reason for this are the high-resolution wheel scrolling patches: > > > > https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 > > > > > > > > Specifically, the question is: do we **change** protocol elements or > > > > behaviour as the interface versions increase? A few random examples: > > > > > > What we can't do is: > > > > > > - Change existing messages' signature > > > - Completely remove a message > > Indeed. > > > It should be relatively easy to modify wayland-scanner to support both > > of these things, *if* we decide that it's a reasonable thing to do. > > (You'd do something like add support for > removed_in="5"/> and the like) > > How would that work, given the version is negotiated at runtime? > > The message signature structs are now ABI as well, and we have no room > for alternate signatures, do we? > > > > > > > > - event wl_foo.bar introduced in version N sends a wl_fixed in > > > >surface coordinates. version N+1 changes this to a normalized > > > >[-1, +1] range. > > > > > > Argument types can't be changed. This would be a breaking change for > > > the > > > generated code, we can't do that. > > > > But this isn't changing the argument type; it's changing the > > interpretation of the argument. > > In both cases the type is wl_fixed; in the first you interpret this > > wl_fixed as being in surface coordinates, in the second you interpret > > it differently. > > > > This doesn't require any changes to code generation; I don't think this > > is (in principle) any more disruptive than changing “wl_foo.baz is > > sent exactly once” to “wl_foo.baz is sent zero or more times”, > > which you're happy with. > > Something we rarely consider is if you pass Wayland protocol objects > into a library without negotiating the object version with the library > first. For example, we pass wl_surface into the EGL Wayland wrapper > library. If wl_surface would get a version bump breaking backwards > compatibility, meaning that version N+1 changes something that existed > in version N, the library handling only version N would fall apart. > > I sincerely hope this is the only case of a library taking a ready-made > Wayland object in. Getting the version negotiation right needs > inconvenient additions to the library API that I don't think many would > bother or even realize it's needed. > > You can query the version of a wl_proxy, sure, but that does not help > you if it returns a number larger than what your code knows about. > > Btw. this is also a problem in the opposite direction. Let's say you > use a toolkit and the toolkit allows you access to the Wayland protocol > objects. Then the toolkit gains support for new interface versions and > uses them, but your app code is not updated. If the protocol change is > backwards incompatible, your app code may break even if only behaviour > changes and not signatures. Yeah, pretty sure we hit this more than once with XI2. X11 has this property too, the client is not monolithic and different parts of it expect different protocol versions and want their own interaction with the protocol stream. If that includes event delivery you suddenly need to be very careful that the app doesn't deselect the events you need... I believe some protocols address this by putting a "channel" abstraction just beneath the client: one socket connection, N channels, each channel has its own ID space, you can share resources among compatible channels but it's an explicit import operation. In X11 terms you could have the GL driver select for the Present / MIT-SHM completion event in its own channel without stomping on the client's main loop state. Of course, for things like XI2, if you have two channels demanding different visible behaviour, you're still up a creek. But you would at least have the possibility that the client could get it right. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol backwards compatibility requirements?
On Thu, 16 Apr 2020 17:47:56 +1000 Christopher James Halse Rogers wrote: > On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > > Hi, > > > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > > wrote: > >> Hi all, > >> > >> This is request for comments on the exact requirements for protocol > >> backwards compatibility for clients binding to new versions of an > >> interface. > >> Reason for this are the high-resolution wheel scrolling patches: > >> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 > >> > >> Specifically, the question is: do we **change** protocol elements or > >> behaviour as the interface versions increase? A few random examples: > > > > What we can't do is: > > > > - Change existing messages' signature > > - Completely remove a message Indeed. > > It should be relatively easy to modify wayland-scanner to support both > of these things, *if* we decide that it's a reasonable thing to do. > (You'd do something like add support for removed_in="5"/> and the like) How would that work, given the version is negotiated at runtime? The message signature structs are now ABI as well, and we have no room for alternate signatures, do we? > > > >> - event wl_foo.bar introduced in version N sends a wl_fixed in > >>surface coordinates. version N+1 changes this to a normalized > >>[-1, +1] range. > > > > Argument types can't be changed. This would be a breaking change for > > the > > generated code, we can't do that. > > But this isn't changing the argument type; it's changing the > interpretation of the argument. > In both cases the type is wl_fixed; in the first you interpret this > wl_fixed as being in surface coordinates, in the second you interpret > it differently. > > This doesn't require any changes to code generation; I don't think this > is (in principle) any more disruptive than changing “wl_foo.baz is > sent exactly once” to “wl_foo.baz is sent zero or more times”, > which you're happy with. Something we rarely consider is if you pass Wayland protocol objects into a library without negotiating the object version with the library first. For example, we pass wl_surface into the EGL Wayland wrapper library. If wl_surface would get a version bump breaking backwards compatibility, meaning that version N+1 changes something that existed in version N, the library handling only version N would fall apart. I sincerely hope this is the only case of a library taking a ready-made Wayland object in. Getting the version negotiation right needs inconvenient additions to the library API that I don't think many would bother or even realize it's needed. You can query the version of a wl_proxy, sure, but that does not help you if it returns a number larger than what your code knows about. Btw. this is also a problem in the opposite direction. Let's say you use a toolkit and the toolkit allows you access to the Wayland protocol objects. Then the toolkit gains support for new interface versions and uses them, but your app code is not updated. If the protocol change is backwards incompatible, your app code may break even if only behaviour changes and not signatures. > >> - request wl_foo.bar introduced in version N takes an int. version > >> N+1 > >>changes wl_foo.bar to take a wl_fixed and an enum. > > > > Ditto. > > > >> - request wl_foo.bar introduced in version N guaranteed to generate > >> a single > >>event wl_foo.baz. if the client binds to version N+1 that event > >> may be > >>sent zero, one or multiple times. > > > > This is fine. > > > >> I think these examples cover a wide-enough range of the possible > >> changes. > >> > >> My assumption was that we only ever add new requests/events but > >> never change > >> existing behaviour. So wl_foo.bar introduced in version N will > >> always have > >> the same behaviour for any interface N+m. > > > > We can change existing requests' behaviour. This has already been > > done a > > number of times, see e.g. wl_data_offer.accept or > > xdg_output.description. > > > > Clients should always have a max-version, ie. they should never > > blindly bind > > to the compositor's version. > > > > What is also fine is marking a message as "deprecated from version > > N". Such a > > message wouldn't be sent anymore starting from this version. > > > >> I've seen some pushback for above linked patchset because it gets > >> complicated and suggestions to just change the current interface. > >> The obvious advantage is being able to clean up any mess in the > >> protocol. > >> > >> The disadvantages are the breakage of backwards compatibility with > >> older > >> versions. You're effectively forcing every compositor/client to > >> change the > >> code based on the version number, even where it's not actually > >> needed. Or, > >> IOW, a client may want a new feature in N+2 but now needs to > >> implement all > >> changes from
Re: can subsurface and shell surface be used together to manage surfaces
On Sun, 12 Apr 2020 17:13:04 +0800 zou lan wrote: > Hi Matt > > yes, I want to bind a wl_surface to a subsurface first, then create a shell > surface for it. No, you can't do that. > I want to do that is because if the wl surface is created by another > compositor, it had been declared as a subsurface to map its position of Another compositor? Do you mean another client? > original compositor. Then weston shell can't > manage the surface as a window directly, I was just wondering how can make > weston shell could manage these kind of surfaces as separate windows too. > It seems create shell surface for each wl surface is not a good idea in > this case. Thank you for confirmation! What are you trying to do? Do you have some sort of middle-man compositor as a third player here? I don't understand at all. Thanks, pq pgp2RRrFoI8i2.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
