Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#29157 - [mesa] --enable-gbm

Attached to Project: Arch Linux
Opened by stubb (stubb) - Wednesday, 28 March 2012, 20:31 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 19 May 2012, 08:17 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture x86_64
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No


Description: Please build the package with --enable-gbm

Additional info:
* package version(s)
* config and/or log files etc.
checking for GBM... no
configure: error: Package requirements (gbm) were not met:
No package 'gbm' found

Steps to reproduce:
I tried to install Kmscon, it is a simple terminal emulator based on linux kernel mode setting (KMS) from .
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 19 May 2012, 08:17 GMT
Reason for closing:  Implemented
Additional comments about closing:  libgbm is now packaged in mesa 8.0.3, if you need further changes open new items.
Comment by Ran Benita (bluetech) - Sunday, 01 April 2012, 18:29 GMT
I might also mention that libgbm is used by the Wayland compositor (Weston) as well. It is not sufficient for making Weston run off of Arch's mesa, but might help in the future.
Comment by David Herrmann (dvdhrm) - Sunday, 01 April 2012, 20:42 GMT
It's the last piece missing to get a working DRM stack on Arch-Linux so I vote for it, too. For the curios, libgbm is the buffer manager which provides driver-independent access to the TTM/etc. layer in the kernel so we can allocate framebuffers and bind them to CRTCs without needing to know the required graphics driver.

I think to enable it in newer mesa, you need --with-egl-platforms=drm,x11 Default is only x11.
Comment by Chad Versace (chadversary) - Saturday, 28 April 2012, 23:18 GMT
I voted for this because plymouth and Weston require it.

David, you should place x11 as the first item in the list supplied to --with-egl-platforms, unless you have a good reason not to. The first platform listed there becomes the default libEGL platform. If x11 is not the default, then X11 apps that use EGL but forget to set the environment variable EGL_PLATFORM can crash in some corner cases.
Comment by David Herrmann (dvdhrm) - Sunday, 29 April 2012, 09:43 GMT
Looking at _eglGetNativePlatform() and _eglNativePlatformDetectNativeDisplay() I cannot understand your concerns. _eglPointerIsDereferencable() must be _false_ so the default platform will be used. However, with an XDisplay this will never be false so the default platform will never be used for X11 applications. Anyway, maybe I am missing something here.

On the other hand, why should X11 be the default? Who uses EGL with X11 if there is glx? It is more likely that egl is used with drm or wayland. However, autodetection is rough anyway so an application should always set EGL_PLATFORM.
Comment by Chad Versace (chadversary) - Tuesday, 01 May 2012, 21:09 GMT
David, the EGL spec allows one to call eglGetProcAddress before calling eglInitialize, and that is when the problem occurs. In that case, there is no display yet, so _eglGetNativePlatform sets detection_method = "build-time configuration", which causes native_platform to take the value of the first item given to --with-egl-platforms. If you later call eglInitialize on a display of a different platform, invalid casts occur and you get undefined behavior.

I encountered the problem when running a GLES2 Piglit test after building Mesa with --with-egl-platforms=wayland,x11. The test was supposed to be run under X11/EGL, but libEGL defaulted to Wayland and the test segfaulted inside libwayland-client.

But, like you said, the autodetection shouldn't be trusted anyway and the application should set EGL_PLATFORM.