raspberrypi
Khronos EGL headers outdated (?)
Hi,
I’m trying to cross-compile WebKitGTK+ 2.20.0 for the Raspberry Pi 2/3 (armv7l) linking it to the libEGL provided by raspberry/userland but get errors like, e.g.,
/builddir/webkitgtk-2.20.0/Source/ThirdParty/ANGLE/src/common/utilities.cpp: In function 'const char* egl::GetGenericErrorMessage(EGLint)':
/builddir/webkitgtk-2.20.0/Source/ThirdParty/ANGLE/src/common/utilities.cpp:950:14: error: 'EGL_BAD_STREAM_KHR' was not declared in this scope
EGL_BAD_STREAM_KHR is defined in eglext.h but it’s missing in the version shipped with userland (which is quite old, 2009).
However, I’m not sure if the problem lies with ANGLE (which also comes with (newer) Khronos headers; but not using them) or userland. The way I understand it is that it should use the headers shipped with the library that’s supposed to be used (which would be libEGL from userland). So in this case: is it possible to bring these headers up-to-date? Or am I getting it wrong?
updating khronos would also render PR #467 unnecessary and would be the right thing to do :)
Can this be revisited? I want to create a context that supports the GL_KHR_no_error extension, but the flag isn't recognised by EGL:
EGL: Failed to create context: An unrecognized attribute or attribute value was passed in the attribute list
I presume it's no coincidence that the relevant defines (https://github.com/KhronosGroup/EGL-Registry/blob/master/api/EGL/eglext.h#L104) are missing from the version of the header in this repository.
Edit: I have checked that the extension is supported by the underlying mesa implementation; it's just a matter of requesting it through EGL.
If you're using the Mesa stack then you should be using the headers from mesa too, not these ones. Probably in libgl1-mesa-dev, but I haven't checked.
@6by9 My issue is that while my application knows how to request the feature, libEGL provided by Raspbian (standard up-to-date release) doesn't understand it. Note that it's not complaining that the feature isn't supported, but that it doesn't recognise the attribute at all. It seems likely to me that an outdated EGL header is the culprit.
Apologies if this is the wrong place to raise such an issue. Should I cross-post to the Raspbian distro issue tracker?
Can you state the location of the header files you are using and the location of the EGL lib you are linking with? There are two different drivers, one living in /opt/vc and one in /usr and it's not clear which you are referring to.
@popcornmix The lib name requested is "libEGL.so.1", which resolves to /usr/lib/arm-linux-gnueabihf/libEGL.so.1 (verified by strace).
I'm not including EGL headers directly in my code (using library glfw3, which just defines the symbols it needs internally), but the relevant constant is #define EGL_CONTEXT_OPENGL_NO_ERROR_KHR 0x31b3, which comes from Khronos' EGL registry.
eglQueryString(display, EGL_EXTENSIONS) contains "EGL_KHR_create_context_no_error", which means it should support the extension (if it didn't, glfw wouldn't try to pass the attribute).
Then eglCreateContext returns an error about the unrecognised attribute.
Having looked into it further, I now realise what I'm seeing is probably completely unrelated to the parent issue. Sorry for the noise. Where should I post my issue instead?
I can confirm that generally the Khronos headers in this repository are largely outdated. For example, they miss the definition of GLsync, which causes a problem when building the GStreamer plugin for Qt. Indeed, GStreamer and Qt both have some logic to define their own GLsync type if the OpenGL headers don't provide it, but they disagree on how to define the type, causing a conflicting type definition. Of course, you could blame Gstreamer and/or Qt for this, but this issue only occurs with the RaspberryPi OpenGL implementation due to its ancient copy of the Khronos headers.
Would it be possible to finally update the Khronos headers to a reasonably recent version, of course ensuring that those headers are compliant with what the RPi OpenGL implementation provides in terms of features and API?
The headers and the firmware side GL driver are deprecated and won't work with default settings under bullseye (i.e. using kms). You should be using the library and headers from the mesa library (i.e. the arm side GL driver) which will be more up to date.
So we should no longer be using the OpenGL blob from this repository? Does the open-source implementation in mesa3d supports all RPi versions, even the oldest ones?
Yes, the mesa driver supports all versions of Pi (although pi0/1 may struggle with memory requirements). If you want your application to work with the latest PRiOS (which uses kms and the arm side drivers), then you should be using the mesa headers and libs.
The firmware drivers still work on bullseye if the kms driver is disabled in config.txt, but as that is deprecated use, the firmware driver will not be getting updated, so no new features or bug fixes.
The arm side drivers are under continuous development, so will be getting new features and bug fixes.