<div dir="ltr"><div>One of my issues is what happens for objects that have multiple parents, like wl_buffer or wl_callback. What do we do if another person wants to introduce another (like the recently proposed pointer lock extension)? We can recommend that users never use wl_callback directly and instead use their own types instead because there's no reason *not* to, but what do we do about wl_buffer? Or others? Do we prohibit that going forward? Do we strongly word against it? Do we invent new versioning rules for those?<br><br></div>What about use cases much like wl_buffer, which really wants a subtyping mechanism? Recommend users use a role mechanism akin to wl_surface? Should we consider adding more infrastructure and helpers in libwayland to support "role-d objects", much like what Pekka added to Weston recently?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 5, 2014 at 5:30 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ping<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 11, 2014 at 1:36 AM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Fri, Apr 11, 2014 at 2:03 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, 10 Apr 2014 09:42:55 -0500<br> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br> <br> > On Thu, Apr 10, 2014 at 6:37 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote:<br> ><br> > > Hi Jason,<br> > ><br> > > thanks for working on this, it does seem very useful, practically a<br> > > mandatory feature to support.<br> > ><br> ><br> > Hi Pekka,<br> > Yeah, I've been itching to knock this out for a while. Just finally got<br> > around to it. Comments below.<br> <br> </div>...<br> <div><div><br> > > On Wed, 2 Apr 2014 09:48:29 -0500<br> > > Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br> > ><br> > > > It's worth noting that there is one small backwards-compatability issue<br> > > > here. Namely, if the client is built against protocol stubs from an<br> > > > earlier version of libwayland but links against a library built against a<br> > > > newer version, then all objects created by the client will report a<br> > > version<br> > > > of 1. This is because the old api uses wl_proxy_marshal_constructor in<br> > > > wl_registry_bind so all objects will inherit the protocol version of<br> > > > wl_display which is 1. The library the client linked against is aware of<br> > > > the wl_proxy_version function but has no way of knowing that the library<br> > > > does not.<br> > ><br> > > I was about to say that wl_registry_bind() does pass the version to<br> > > wl_proxy_marshal_constructor, but that indeed is in the request<br> > > arguments and not a mandatory argument.<br> > ><br> > > But wl_proxy_marshal_constructor() would still have all the information<br> > > it needs, if we special-case wl_registry.bind inside it. Ugly, but I<br> > > guess it'd work for wl_registry. Would that make the<br> > > backward-compatibility issue go away? In all other cases you would take<br> > > the version from the parent wl_proxy, which you always have available<br> > > in wl_proxy_marshal_constructor(), and the versioned variant would not<br> > > be needed?<br> > ><br> ><br> > Yes, we could do that, and I considered it. However, it would only bump<br> > the compatibility issue back to wl_proxy_marshal_constructor. Older code<br> > that uses wl_proxy_create inside of wl_registry_bind is still in trouble.<br> > I don't think it's a huge savings to just bump the compatibility issues<br> > back to 1.3 rather than 1.4/1.5. In the long run, I don't think it's worth<br> > the mess that we would create inside wl_proxy_marshal_constructor.<br> <br> </div></div>Ok, I didn't even know to think that far back. Makes sense.<br> <div><br> > > But I guess it would still be broken on any other request that used the<br> > > interfaceless format of new_id?<br> > ><br> ><br> > Nope, that's not a problem. The wayland-scanner program doesn't actually<br> > special case wl_registry_bind but interfaceless new_id's in general.<br> > Anything else that specifies a new_id with no interface will hit the same<br> > code-path and get wl_proxy_marshal_constructor_versioned.<br> <br> </div>I meant if we special-case wl_registry.bind, then all other requests<br> using interfaceless new_ids would still be in trouble. But yes, a moot<br> point now.<br> <div><br> > > > One possible solution for this is to set the version of wl_display to<br> > > zero<br> > > > and use zero to mean "unversioned". Then, if a library wants to use<br> > > > something that's not strictly backwards-compatable, it can check for zero<br> > > > and use whatever it's non-versioned fallback is.<br> > ><br> ><br> > Thoughts on this? ^^<br> <br> </div>Well... if you don't know the version, is there a difference between<br> assuming it is 1, and knowning it is unknown and then assuming whatever?<br> <br> As I see it, the only benefit of knowing when you don't know, is that<br> you could then explicitly assume a higher version than 1, and then die<br> on a protocol error if you are wrong. I'm not sure if that is better<br> than assuming 1 which will always work if the application only accepts<br> that.<br></blockquote><div><br></div></div></div><div>There is a case where I would do something different on unknown vs. version == 1. In fact, it's the exact came case that inspired me to actually sit down and write this. The wl_surface.damage request, from the perspective of EGL implementations, is completely broken on wl_surface versions 2 and 3 (trying to fix it for 4). An EGL implementation could check for unknown, 2, or 3 and just do wl_surface.damage(0, 0, INT32_MAX, INT32_MAX) in both eglSwapBuffers and eglSwapBuffersWithDamageEXT to work around this. Then, if the version is 2 or >= 4, they could just damage the surface correctly. It's kind of a specific example and the only reason why we care is because we broke stuff at wl_surface version 2 but it's an example.<span><font color="#888888"><br> <br></font></span></div><span><font color="#888888"><div>--Jason<br></div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It looks like a trade-off between an "unknown method" protocol error /<br> events that never come, and the application complaining the server is<br> too old, when things go wrong.<br> <br> I can't say.<br> <br> <br> Thanks,<br> pq<br> </blockquote></span></div><br></div></div> </blockquote></div><br></div> </div></div><br>_______________________________________________<br> wayland-devel mailing list<br> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br> <br></blockquote></div><br><br clear="all"><br>-- <br> Jasper<br> </div>