[Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get

[Emil Velikov]

On 15 September 2017 at 15:13, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 15 September 2017 at 14:30, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 15 September 2017 at 14:04, Daniel Stone <daniel at fooishbar.org> wrote:
>>> I'd be slightly wary of this current series. Currently, both
>>> libwayland-server.so and libwayland-client.so define
>>> wl_buffer_interface separately:
>>> strictly:~/misc/visa% objdump -x
>>> ~/prefix/wayland/lib/libwayland-server.so.0.1.0 | grep wl_buffer_int
>>> 0000000000212e40 g     O .data.rel.ro 0000000000000028
>>> wl_buffer_interface
>>> strictly:~/misc/visa% objdump -x
>>> ~/prefix/wayland/lib/libwayland-client.so.0.3.0| grep wl_buffer_int
>>> 000000000020dea0 g     O .data.rel.ro 0000000000000028
>>> wl_buffer_interface
>>
>> Right, I tried to address that but there were some objection from
>> yourself/Pekka.
>
> Kinda, yes. I was certainly against breaking our ABI in order to not
> export the symbols; it would've been great if they weren't exported
> originally, but they are and we just have to live with it until we
> decide that we want everyone using Wayland to change their code and
> build system and recompile in one big flag day.
>
> But if you avoid wl_resource_instance_of() and replace it with
> wl_resource_get_destroy_listener(), you can side-step the problem, by
> not relying on consistent resolution of wl_buffer_interface. That's a
> real bugfix. :)
>
Right, I'm looking through both functions and I'm struggling a bit.
Can I bother you with sending a patch?

>>> I'll grant you that it's basically pot luck as to which one is
>>> resolved first, but if we remove the wayland-server linkage, it seems
>>> more prone to pick the wayland-client interface, i.e. the wrong one.
>>>
>>> Changing the wl_resource_instance_of() call into
>>> wl_resource_get_destroy_listener() would be far more foolproof, but it
>>> doesn't remove the need for linkage.
>>>
>> The patch removes the libwayland-drm.la linkage, not the
>> wayland-client/server one.
>> I don't think it makes sense to remove the wayland-server link for
>> gbm, since it's (sort of) a server.
>>
>> The original confusion is (hopefully) unwrapped with the next patch -
>> where users are linked only against what they should.
>> Namely, as wayland platform is selected:
>>
>> libgbm -> libwayland-server
>> libEGL -> libwayland-client + libwayland-server if drm/gbm platform is toggled.
>> Last one is for the eglBindWaylandDisplay EGL <> GBM interop with wl_drm.
>
> Nested compositors rely on eglBindWaylandDisplayWL() as well: if you
> start Weston under a Wayland compositor, it will call
> BindWaylandDisplay in order to export acceleration to its own clients.
> So even if the DRM/GBM Wayland platform isn't active, libEGL should
> still be linked to libwayland-server, unfortunately.
>
Ehh... sounds like we a bug in libEGL ;-)

This patch cleans up some unneeded inter-dependencies, as a bonus
making libgbm.so ~3KiB smaller.
It'll be great to have but nothing crucial really.

-Emil