EGL init problem

[Christopher Barry]

On Fri, 16 Oct 2015 13:03:14 +0900
Michel Dänzer <michel at daenzer.net> wrote:

>On 16.10.2015 12:43, Christopher Barry wrote:
>> On Fri, 16 Oct 2015 11:50:27 +0900
>> Michel Dänzer <michel at daenzer.net> wrote:
>> 
>>> On 15.10.2015 22:33, Christopher Barry wrote:
>>>> On Thu, 15 Oct 2015 11:16:03 +0900
>>>> Michel Dänzer <michel at daenzer.net> wrote:
>>>>
>>>>> On 15.10.2015 02:47, Christopher Barry wrote:
>>>>>> On Wed, 14 Oct 2015 10:35:23 +0900
>>>>>> Michel Dänzer <michel at daenzer.net> wrote:
>>>>>>
>>>>>>> On 14.10.2015 04:14, Christopher Barry wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Can someone help me with the correct incantation to compile X
>>>>>>>> git-master for hw-accel with an AMD R9 380?
>>>>>>>>
>>>>>>>> Using --modfile w/ build.sh, and have tried the following (each
>>>>>>>> on a single line in the modules-file):
>>>>>>>>
>>>>>>>> mesa/mesa --enable-dri --enable-dri3 --enable-glx
>>>>>>>> --enable-glx-tls --enable-egl --enable-gbm
>>>>>>>> --enable-shared-glapi --enable-gallium-llvm
>>>>>>>> --enable-llvm-shared-libs --enable-r600-llvm-compiler
>>>>>>>> --with-llvm-prefix=/opt/lib/llvm/ --with-egl-platforms=x11,drm
>>>>>>>> --with-dri-drivers=r300,r600,radeon,svga,swrast
>>>>>>>> --with-gallium-drivers=r300,r600,radeonsi,svga,swrast
>>>>>>>>
>>>>>>>> xserver --enable-glamor
>>>>>>>>
>>>>>>>>
>>>>>>>> I get the following errors in my log Xorg.0.log:
>>>>>>>>
>>>>>>>> (EE) RADEON(0): glamor detected, failed to initialize EGL.
>>>>>>>> (EE) AIGLX: reverting to software rendering
>>>>>>>
>>>>>>> Please provide the full Xorg.0.log file.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks  Michel,
>>>>>>
>>>>>> I recompiled with --with-dri-drivers=''.
>>>>>>
>>>>>> log attached
>>>>>
>>>>> [...]
>>>>>
>>>>>> [     9.337] couldn't get display device
>>>>>
>>>>> This means gbm_create_device() returns NULL. I suspect it may not
>>>>> be picking up some of your self-built Mesa binaries, e.g.
>>>>> libgbm.so.1. I'd try running Xorg in strace to see where it's
>>>>> picking that up from.
>>>>>
>>>>
>>>> Here's what the linker is returning - I *think* that should tell us
>>>> without tracing.
>>>>
>>>> [-][~]:: ldconfig -p | grep libgbm
>>>> libgbm.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgbm.so.1
>>>> libgbm.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgbm.so
>>>>
>>>> So, correct you are. It's showing the libs only in the standard
>>>> packaged X location.
>>>>
>>>> Doing a find for the libs in /opt, which is where I'm putting
>>>> stuff:
>>>>
>>>> [-][~]:: find /opt/ -type f -name "*libgbm*"
>>>> /opt/xorg-orig/lib/libgbm.so.1.0.0
>>>> /opt/xorg-orig/lib/libgbm.la
>>>>
>>>> ...and they're found /only/ in the first build of xorg I did a
>>>> month or more ago, which I've since renamed to xorg-orig.
>>>>
>>>> The xorg I'm running now is rooted in /opt/xorg-new, which does not
>>>> have these libs at all. What switch am I missing that is not
>>>> getting them built? Does a different module in modules-file need a
>>>> parameter to build gbm? I do have --enable-gbm set for mesa/mesa,
>>>> so I'm confused as to why they are not getting built.
>>>> mesa/mesa/config.log has HAVE_GBM_FALSE='' and HAVE_GBM_TRUE='#'
>>>> set.
>>>>
>>>> I've attached that config.log as well for your perusal if it might
>>>> be helpful.
>>>
>>>From the top of config.log:
>>>
>>>> Invocation command line was
>>>>
>>>>   $ ./configure --prefix=/opt/xorg-new
>>>
>>> So your parameters aren't getting passed to Mesa's configure.
>>>
>>>
>> 
>> Yeah, I saw that and wondered myself. I figured because they were set
>> as parameters to mesa in the --modfile file that build.sh uses, that
>> they must get passed in somewhere else. I've used the modules file
>> method before, and the params in the file were used, so it used to
>> work anyway.
>
>I don't know any other way of passing arguments to configure scripts,
>and there's no other trace in config.log of --enable-gbm or
>--with-egl-platforms=x11,drm being passed in.
>
>I think you need to look into how build.sh is supposed to pass the
>arguments to Mesa's configure script and why it's not happening.
>
>

It's a pretty big script, and I will investigate if it fails again from
a completely new clone. For now, I'm hoping that'll jiggle the handle...

Any thoughts on verbose debug logging? Is there a global for that?

Thanks,
-C