[PATCH weston] rpi: avoid vc_dispmanx_set_wl_buffer_in_use without EGL

[Tomeu Vizoso]

On 23 November 2013 10:30, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 22 Nov 2013 17:26:58 +0000
> Daniel Stone <daniel at fooishbar.org> wrote:
>
>> Hi,
>>
>> On 22 November 2013 15:30,  <ppaalanen at gmail.com> wrote:
>> > The symbol is needed only for the EGL buffer path. If --disable-egl is
>> > given to ./configure, there is no need for it, so fix it to actually not
>> > look for that symbol needlessly.
>> >
>> > This should fix the runtime error:
>> >
>> >         Failed to load module: .../rpi-backend.so: undefined symbol:
>> >         vc_dispmanx_set_wl_buffer_in_use
>> >
>> > when you use --disable-egl and do not have a recent enough
>> > libraspberrypi package (/opt/vc, a.k.a userland.git) that would provide
>> > vc_dispmanx_set_wl_buffer_in_use. Apparently no released version of
>> > userland yet provides this.
>> >
>> > The calls are organized into two helper functions to avoid a boolean
>> > argument, and put the #ifdefs away from the main parts of the code.
>>
>> If you really wanted to gold-plate it, you could call it through dlsym
>> instead to avoid the link error altogether, even when someone builds
>> with --enable-egl, but doesn't have the support from the vendor
>> libraries?
>
> If someone did that, they'd be missing all EGL support anyway, no?
>
> So using --enable-egl would have been in vain in the first place,
> we'd just silently not enable it after all. I think that would be
> fairly many functions to dlsym, too.
>
> I could do that if you really see use for it, but I don't see it that
> useful. Our build guide still has --disable-egl. Making that work
> was my goal.
>
> If we had a configure check when --enable-egl on rpi to see
> that the function declarations are in the /opt/vc headers, we could
> make it complain of an unsupported combination at configure time.

Yeah, I would go with the least invasive solution for now, as Wayland
support in rpi's EGL is something we still think is going to happen
any day from now.

This looks good to me, even if I slightly prefer set_in_use over _lock
because I feel the term locked has a bit less of meaning.

Reviewed-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>

Regards,

Tomeu