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

[Michel Dänzer]

On 09/01/17 08:08 PM, Christian König 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)

That would probably just result in users moving ~/.drirc to ~/.mesarc,
or creating a symlink?


> 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

What exactly is that pain, and why is removing support for ~/.drirc
altogether the only solution for it? There needs to be solid
justification for such a radical change.

And does this actually solve the problem? Users can still shoot
themselves in the foot via the corresponding environment variables
(which this patch would force them to use). The only difference is that
there's a message on stderr about driconf options set via environment
variables, which is why I suggested printing similar messages for
options set via ~/.drirc.

For similar reasons, I'm skeptical that Edmondo's patch would actually
solve the problem, or even that it'd help enough to make up for the
inconvenience it would cause users relying on this functionality.


> for questionable gain.

Why do you think so? This functionality has been around for well over a
decade. As usual with this kind of thing, we only tend to hear from
people having problems, so we can't know how many people are using this
functionality without problems.


I think what's really needed is a way for us to be able to tell which
driconf settings are in effect for a user. Apart from printing messages
for settings in ~/.drirc files (possibly even by default, without any
environment variable), simply asking for the contents of the ~/.drirc
file in problem reports might go a long way.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer