I was reading almost 80% of the discussion
and want to give you a quite "bold" sheme
of how that all can be handled in terms of
a real world system:
You'd write an extension to the drivers that
advertises all queried enviromental strings.
This should resemble a similar checking sheme
as it is done for the exported gl extensions,
the known driver specific config file options
and for the imported XF86 module symbols.
Any advertised environmental string is allowed
by the XF86 system to be parsed by the drivers.
On the client side there is a shell application
which i will call `gltune` right now. This
application just queries the libGL and the
driver behind it for their respective environment
parameters and further can query their current
state and their default state. This application
is able to write those values out to the shell:
# current settings of "libGL" version 1.2
LIBGL_ALWAYS_INDIRECT=0
LIBGL_NUMBER_OF_LIGHTS=4
# current settings of "r200" version 4.1.0
LIBGL_NO_TCL=0
LIBGL_MAX_LOD=6
(looks quite similar to what you might see with Samba config.)
With this outputs you will get a full overview
about the current state. You should be able to pass
that data back to the shell. There should be a
gltune program option that prefixes varies the outputs
so that e.g. "." sourcing with the bash is possible.
For this there is no need for a write back option for the program
but its possible to allow the program to perform the "wrong" way.
Anyways, i dont think global options should get merged into such
a per-client and per-terminal sheme.
Of course there is a possibility of attaching a GUI
tool to that "ENV-NAMES" extension, which then might
make up Profile management, allowing to have a big
bunch of help file in some central location and other
ways of giving the ordinary skilled user good hints
on every reported environment setting.
Sample:
Profile: Quake3 [Load] [Save] [Reset]
[page1] [page2] [page3]
Accelleration Level: [help]
( ) software rendering
(o) hardware rendering w/o TCL
( ) hardware rendering with TCL
[x] LIBGL_AA - enforces antialising [help]
[6] LIBGL_MAX_LOD - level of detail [help]
[browse unclassified only] [browse all]
[Launch Application] [Launch Shell] [Quit]
I am not a TCL/TK freak or whatever, but i think
a set of config files should provide all extra
information for a specific grafics adapter or
if there is not yet a tailored config then
it recognizes at least the basic switches
and offers the remaining e.g. in an alphabethic
listing. "Help" should be quite easy to maintain.
You might get the idea behind now.
I mean that will be ease of use - and it must
really not break with the existing sheme.
It's just a front end for serving to the low level.
There is one drawback that i should not be silent about:
you will not be able to deal with large amounts of
environmental variables effectively because that
checking and counter checking against lists will be
time consuming. Generic vars like "LIGHT_1" trough
"LIGHT_32767" arent target of those simple sheme.
You see you can get anything from shell variables.
Even the GUI frontend and the profiles. Flexibility
is the nature of the shell vars in contrast to
binary interfaces where you always have to fear
about compatibility if only a single change happens.
-Alex.
