On Wed, Dec 04, 2002 at 01:57:48PM -0700, Nicholas Leippe wrote: > On Wednesday 04 December 2002 01:06 pm, you wrote: > > > > I basically see three camps in this discussion: > > > > 1. Users should be able to configure default behavior using configuration > > files (which would be selected based on argv[0] or similar) > > > > 2. Users should be able to configure default behavior using environment > > variables (which would be configured on a per-application basis using > > wrapper scripts or a launcher program or similar) > > > > 3. Users should not be able to configure default behavior; applications > > should specify all behavior explicitly if it matters, and expose this as an > > application-level configuration option to the user > > It seems to me that 2 and 3 are independent. I don't see why the > application's configuration doesn't just provide an interface to changing > it's own environment variables. This would allow wrapper scripts to supply > variables/values the application didn't know about when written, and let the > application provide a nice interface to the user for changing them as well.
The problem with 3 is that then new features can't necessarily be added back into older closed-source applications. For example, FSAA and anisotropic filtering and so on. It could be easily overridden at the libGL level (using LD_PRELOAD) without requiring lots of cruft in the drivers themselves; I don't see why the drivers should get unnecessary functionality like this when it could be provided by external solutions (external both to the drivers *and* the applications). > Wrapper scripts can provide both default settings (bashrc) or per-application > settings just the same. One would hope that the individual applications aren't using environment variables to store all of their configuration. :P > It seems as if none of the levels of controls people have been asking for in > this thread can't be satisfied via environment variables in one way or > another--it seems to be the most flexible solution. What about remote indirect rendering? Someone else has already mentioned that the driver would have no way of getting environment variables in that case. I just don't see why everyone wants to put this functionality into the driver itself; IMO, it just adds unnecessary complexity to the drivers. The purpose for an LD_PRELOADed library would be to provide tweaks to applications which *don't* provide the configuration. Which is really the whole issue here - people want to be able to configure behavior that certain applications don't allow to be configured. There's no reason for the driver to do this, and for those applications where the source can't be modified, why not just LD_PRELOAD the functionality in externally? -- http://trikuare.cx ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
