[Mesa-dev] [PATCH] st/dri: Fix driver loading if swrast isn't built

[Aaron Watry]

On Sun, Aug 3, 2014 at 12:30 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 03/08/14 18:13, Aaron Watry wrote:
>> On Sun, Aug 3, 2014 at 12:00 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> <SNIP>
>> Yup, when I finally managed to bisect this down to the commit that
>> added the kms_swrast_create_screen function, I went back to the commit
>> before that so I could boot X, then applied the kms_swrast commit and
>> LIBGL_DEBUG=verbose glxinfo told me that it was missing
>> kms_swrast_create_screen when loading radeonsi_dri.so.
>>
> Ouch, sorry about that.
>
> For a future reference please give new libGL/DRI modules a try (via
> LD_LIBRARY_PATH & LIBGL_DRIVERS_PATH) before installing them system-wide.
>

I always keep my local copies of drivers in /usr/local/ so that if
something breaks, I can just "sudo mv /usr/local/lib
/usr/local/lib.bak && sudo ldconfig" and I have a working system again
(yeah, I should just test out of ~/src/mesa, but this fallback method
has worked quite well for me in the past).  The reason that this ended
up being an issue this time is that I actually updated my system
against the latest distro packages, which also included a broken
radeonsi driver (Ubuntu 14.04 + xorg-edgers ppa).  The only way I was
able to recover was by either a) removing all distro packages and also
rolling back mesa to a working commit, or b) purging the xorg-edgers
ppa which downgraded mesa to 10.1.x.

The thing that made the issue harder to track down was that all of my
xorg log messages indicated that EGL itself was failing to initialize,
and so I spent a while headed down the wrong path trying to
troubleshoot EGL (the commit immediately before the kms_swrast one
made some egl changes) instead of checking if the driver wasn't
actually loading.

Enough said.  Problem is solved, and I think I've learned enough to
reduce my troubleshooting time if it happens again.

--Aaron

>> It took me a few days of effort here and there to eventually track
>> down what failed (debugging issues when you can't launch X at all is a
>> bit slower than usual), and if we can make this an error at build/link
>> time, that would've been a huge time saver.
>>
>> Would you mind looking into that?  Or should I poke at it when I have time?
>>
> I've already did and I go stuck as old (pre 1.14 iirc) xserver used to provide
> the symbols, which we used due to the gl dispatch in our server-side libglx.so.
>
> Would be great if someone more knowledgeable in the area give us a few tips
> and hints on the topic.
>
> Adam are we safe to start linking the dri modules against libglapi ? Any ideas
> how that will affect backwards compatibility - i.e. using new mesa + old xserver ?
>
> Thanks,
> Emil
>
>> --Aaron
>>
>>
>>> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
>>>
>