[agl-discussions] Issue : Qt5 examples with wayland-egl plugin deos not work by 'EGL not available'

Al-Khanji Louai louai.al-khanji at theqtcompany.com
Wed Sep 23 06:45:57 UTC 2015


(Resending this e-mail as it looks like something went wrong with the previous one)

On ke, 2015-09-23 at 13:49 +0900, Tadao Tanikawa wrote:
> When trying to run Qt5 EGL examples, they all stop by same error, 'EGL not available'.
> As a result of further investigation, it is probably caused by proprietary binaries provided by Renesas for porter board.
>

We have actually run into this issue previously with a different Renesas
board.

The issue is with the way the eglGetDisplay interface works. This
function takes a void* and must determine somehow what the pointer
refers to so that it can initialize the right subsystems.

With QtWayland, the call to eglGetDisplay is in
qtwayland/src/hardwareintegration/client/wayland-egl/qwaylandeglclientbufferintegration.cpp, specifically in QWaylandEglClientBufferIntegration::initialize - that's where the "EGL not available" message comes from.

The pointer that is passed to eglGetDisplay in this case is the
wl_display handle that wl_display_connect returns. Within the PVR EGL
implementation something goes wrong when inspecting this pointer.

I don't have access to the source code for libpvrEWS_WSEGL.so, but as
far as I can tell the library internally compares the pointer to the
symbol wl_display_interface. This is where the problem lies - the symbol
is defined and exported both in libwayland-server.so and in
libwayland-client.so! Which one is used depends entirely on the linking
order of these two libraries.

This issue has also been discussed on the wayland-devel mailing list,
specifically in this thread:
http://lists.freedesktop.org/archives/wayland-devel/2014-October/thread.html#17783

We independently reported the same issue to Renesas right around that
time as well, but unfortunately never heard anything back.

In the longer term, the "right" way to fix this is for the EGL stack to
implement EGL_KHR_platform_wayland and for QtWayland to start using
that. When I last checked, this was not yet supported with the PVR
drivers.

In the short term, you can try to modify the linking order of the two
wayland libraries. It's been a year so I don't recall the exact steps
off the top of my head, but it should suffice to link the final
executable to both -lwayland-server and -lwayland-client, _in that
order_ specifically. Clearly a hack, but it worked for us when we had
the issue.

MESA in fact also has a similar issue, which is why in
QWaylandEglClientBufferIntegration::initialize the environment variable
EGL_PLATFORM is set to "wayland". That bypasses the autodetection logic
inside MESA, but the PVR stack does not appear to support this variable.

Unfortunately I cannot test any of this myself since I do not have the
required hardware, but I hope the explanation helps.

Cheers,
Louai



More information about the automotive-discussions mailing list