On Wed, Dec 04, 2002 at 12:06:20PM -0800, magenta wrote: > On Wed, Dec 04, 2002 at 11:06:01AM -0800, Allen Akin wrote: > > On Wed, Dec 04, 2002 at 12:57:44AM -0600, D. Hageman wrote: > > | This illustrates one of the bad points of using environment variables. > > | Will we have to add environment variables every time a new app is pushed > > | out the door? Bad approach. > > > > In general, if a bug affects every app, then the driver needs to be > > fixed. Ian's scenario (and my reply) were about the case in which you > > want to change driver behavior for one app without affecting others. > > But this isn't about application bug workarounds, it's about users > specifying hinting or forcing extensions to be active or whatever.
As I pointed out in another post, the same mechanism could be used for both. There are enough corner cases in the OpenGL spec that an application could do something that would just happen to work fine with one dirver, but crash horribly on another. If that were to happen in, say, Maya or Doom 3 or some other commercial app, the common practice on other systems is to provide a driver based work around. The ideal sollution is to fix the app, but not all developers move at the speed of open source. :) > 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 > > Personally, I'm torn between camps 1 and 3. In terms of policy, camps 1 and 2 really are the same. The difference between 1 and 2 is just a matter of mechanism. > Actually, I just thought of a solution which could possibly satisfy all > three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which > overrides functionality as needed. Want to force FSAA to be enabled? Put > it into glXCreateContext(). Want to force GL_RGB8 when the application > chooses GL_RGB? Do it in glTexImage(). Hey, if you want to force GL_RGB4 > when the application chooses GL_RGB8, you could do that too! > > Basically, I see no reason to put this configuration into the drivers > themselves, as it could easily be done using an LD_PRELOADed library. I think that is not a good idea. We want to DISCOURAGE replacing / modifying core libraries. Not only that, virtually all of the behavior that has been discussed here is device-dependent. libGL.so is device-independent. I don't really see a point in having a device-dependent wrapper. That introduces the additional problem of having to have the wrapper libGL.so and the *_dri.so in sync. I see only head-aches down that path... -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ------------------------------------------------------- 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
