On 21/07/14 16:25, Ilia Mirkin wrote:
> On Mon, Jul 21, 2014 at 11:23 AM, Kristian Høgsberg <k...@bitplanet.net>
> wrote:
>> On Sun, Jul 20, 2014 at 11:36 PM, Eric Anholt <e...@anholt.net> wrote:
>>> Emil Velikov <emil.l.veli...@gmail.com> writes:
>>>
>>>> On 18/07/14 17:27, Kenneth Graunke wrote:
>>>>> On Friday, July 18, 2014 07:41:57 AM Dylan Baker wrote:
>>>>>> Currently mesa searches for two different environment variables,
>>>>>> LIBGL_DRIVERS_PATH and GBM_DRIVERS_PATH. The first is used for search
>>>>>> for DRI drivers in every case except GBM, and the latter is used
>>>>>> exclusively for setting GBM drivers. This patch simplifies things by
>>>>>> having just one variable to set.
>>>>>>
>>>>>> Signed-off-by: Dylan Baker <baker.dyla...@gmail.com>
>>>>>> ---
>>>>>> src/gbm/backends/dri/gbm_dri.c | 4 ++--
>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/src/gbm/backends/dri/gbm_dri.c
>>>>>> b/src/gbm/backends/dri/gbm_dri.c
>>>>>> index 347bc99..9d9d1c4 100644
>>>>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>>>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>>>>> @@ -212,8 +212,8 @@ dri_load_driver(struct gbm_dri_device *dri)
>>>>>>
>>>>>> search_paths = NULL;
>>>>>> if (geteuid() == getuid()) {
>>>>>> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
>>>>>> - search_paths = getenv("GBM_DRIVERS_PATH");
>>>>>> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
>>>>>> + search_paths = getenv("LIBGL_DRIVERS_PATH");
>>>>>> }
>>>>>> if (search_paths == NULL)
>>>>>> search_paths = DEFAULT_DRIVER_DIR;
>>>>>>
>>>>>
>>>>> I'm definitely a fan of moving to LIBGL_DRIVERS_PATH for everything -
>>>>> GBM_DRIVERS_PATH is just another environment variable to forget to set
>>>>> properly.
>>>>>
>>>>> As is, this is:
>>>>> Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
>>>>>
>>>>> Are people okay with just moving to LIBGL_DRIVERS_PATH completely like
>>>>> this? Or do people want it to check GBM_DRIVERS_PATH then fall back to
>>>>> LIBGL_DRIVERS_PATH? Or use $GBM_DRIVERS_PATH:$LIBGL_DRIVERS_PATH?
>>>>>
>>>> A few thoughts of a blurry mind (sorry I'm out of coffee):
>>>>
>>>> I can envision at least at couple of use-cases where either of the above
>>>> will
>>>> cause more harm than good, yet I feel that affected people will come here
>>>> after spending hours of debugging/bisecting.
>>>>
>>>> IMHO the "one variable to rule them all" while convenient (set only
>>>> LIBGL_DRIVERS_PATH in your debug scripts/session), is not at all useful. If
>>>> the only issue is "I always forget to set it", I believe that it's not a
>>>> thing
>>>> that should be addressed in mesa.
>>>
>>> I definitely lost out recently because there are two different
>>> variables, and I can't come up with any reason to have two. What cases
>>> are you thinking of?
>>
>> It's a historical accident more than anything. It wasn't designed to
>> work this way for any particular reason. My only comment is that we
>> should try getenv("GBM..") if getenv("LIBGL..) returns NULL. That
>> doesn't seem like a big maintenance burden and avoids breaking
>> anybodys scripts.
>
> Probably a good idea, at least for a while. I think Emil's concern was
> if you're doing a bisect, depending on which side of this commit
> you're on, you'd have to use one or the other variable. This would be
> very annoying.
>
That is one of the points - changing behaviour, before you rely on GBM to do
the right thing, but now it . Another one is using variables that are supposed
to control GBM, called LIBGL*. And the final one flexibility - if you have
some weird combination where you working on GL, EGL or GBM and your change
breaks the other two you might want to isolate that.
IMHO
- If you want to control the world using one variable - call it WORLD*, not a
SPECIFIC_PART_OF_MESA*.
- If the documentation is missing (as with this example) - add two lines in
the documentation.
- If one forgets to set the variable - welcome to my world. In two minutes I
won't remember where my coffee mug is :)
All this has turned out to be a bigger bikeshed that I would have liked to. Do
as you wish gents, I'm not objecting. I hope I'm not the only one that sees
some sense in the above three points.
</bikeshed>
> [Of course I never quite understood the point of this in the first
> place... doesn't LD_LIBRARY_PATH just work for everyone? There's
> probably some use-case I'm not thinking of...]
>
I'm guessing that it's due to some programs/scripts manually fiddling with it,
yet there could be something more to it.
Cheers,
Emil
> -ilia
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
