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 <mic...@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.ol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
