[Mesa-dev] [PATCH] dri: don't load .drirc from $HOME

[Edmondo Tommasina]

Could be a patch like this useful for power users?

Load custom drirc only when specified in env variable.

Patch untested, not even compiled.

edmondo (on mobile phone)

diff --git a/docs/envvars.html b/docs/envvars.html

index cf57ca5..a404ced 100644

--- a/docs/envvars.html

+++ b/docs/envvars.html

@@ -114,6 +114,7 @@ glGetString(GL_SHADING_LANGUAGE_VERSION). Valid values
are integers, such as

if it's higher than what's normally reported. (for developers only)

<li>MESA_GLSL - <a href="shading.html#envvars">shading language compiler
options</a>

<li>MESA_NO_MINMAX_CACHE - when set, the minmax index cache is globally
disabled.

+<li>MESA_CUSTOM_DRIRC - load custom drirc file.

</ul>



diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c

index a8f7c9b..c36b78a 100644

--- a/src/mesa/drivers/dri/common/xmlconfig.c

+++ b/src/mesa/drivers/dri/common/xmlconfig.c

@@ -944,8 +944,7 @@ static void parseOneConfigFile (XML_Parser p) {

 void driParseConfigFiles (driOptionCache *cache, const driOptionCache
*info,

                                                int screenNum, const char
*driverName) {

-    char *filenames[2] = { SYSCONFDIR "/drirc", NULL};

-    char *home;

+    char *filenames[2] = { SYSCONFDIR "/drirc",
getenv("MESA_CUSTOM_DRIRC") };

     uint32_t i;

     struct OptConfData userData;

@@ -956,17 +955,6 @@ void driParseConfigFiles (driOptionCache *cache, const
driOptionCache *info,

     userData.driverName = driverName;

     userData.execName = GET_PROGRAM_NAME();

-    if ((home = getenv ("HOME"))) {

-              uint32_t len = strlen (home);

-              filenames[1] = malloc(len + 7+1);

-              if (filenames[1] == NULL)

-                  __driUtilMessage ("Can't allocate memory for
%s/.drirc.", home);

-              else {

-                  memcpy (filenames[1], home, len);

-                  memcpy (filenames[1] + len, "/.drirc", 7+1);

-              }

-    }

-

     for (i = 0; i < 2; ++i) {

               XML_Parser p;

               if (filenames[i] == NULL)

@@ -987,8 +975,6 @@ void driParseConfigFiles (driOptionCache *cache, const
driOptionCache *info,

               parseOneConfigFile (p);

               XML_ParserFree (p);

     }

-

-    free(filenames[1]);

}

 void driDestroyOptionInfo (driOptionCache *info) {



On Jan 9, 2017 12:08, "Christian König" <deathsimple at vodafone.de> wrote:

> Am 09.01.2017 um 11:58 schrieb Marek Olšák:
>
>> On Mon, Jan 9, 2017 at 7:25 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>
>>> On 09/01/17 03:13 PM, Michel Dänzer wrote:
>>>
>>>> On 07/01/17 11:46 PM, Marek Olšák wrote:
>>>>
>>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>>
>>>>> ~/.drirc is created by the driconf tool (GPL license) and it overrides
>>>>> system drirc settings and can't be changed by Mesa updates.
>>>>> This drops support for the tool. It has been a source of major pain
>>>>> for us and it continues to cause problems.
>>>>>
>>>>> If people wanna keep this and enjoy the pain, I will make a v2 that
>>>>> applies it to radeon drivers only.
>>>>>
>>>>> v2: update comments and docs
>>>>>
>>>> The problem is the driconf application (and possibly documentation
>>>> recommending its use), not the ~/.drirc file. This is throwing out the
>>>> proverbial baby with the bathwater. Fix the problem instead.
>>>>
>>> As for something that could be done about this issue in Mesa, how about
>>> adding terminal output about which driconf options are set to what
>>> values from where, enabled e.g. via LIBGL_DEBUG=verbose ?
>>>
>> That would have no effect on anything whatsoever. The idea is to drop
>> support for driconf. That can be done by not loading ~/.drirc and
>> either:
>> - not loading anything, or
>> - load a different file from HOME instead (e.g. ~/.mesarc)
>>
>
> I would start slower and at-least allow for a grace period or getting rid
> of this.
>
> E.g. if ~/.drirc is present give a big warning on stderr that this is
> deprecated for at least one major release.
>
> If we then find that we need a per user configuration file we can still
> add support for ~/.mesarc.
>
> But in general I agree that file caused quite some pain for questionable
> gain.
>
> Regards,
> Christian.
>
>
>> driconf uses GPL, which is not compatible with X.Org and Mesa.
>>
>> Marek
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170109/4e88f45a/attachment.html>