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

[Daniel Stone]

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. :)

>> 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.

Cheers,
Daniel