Index:
[thread]
[date]
[subject]
[author]
From: Marcus Sundberg <e94_msu@e.kth.se>
To : ggi-develop@eskimo.com
Date: Wed, 08 Jul 1998 11:17:50 +0200
Re: set_mode complexity
I agree with Emmanuels reply on all points.
However this issue is sort of related to another issue
which we discussed very briefly some time ago.
Namely the fact that on a gfxboard without dualported
video-RAM you probably don't want to run games in
160 Hz even if your hardware happens to support it.
Also, that fact that most modern monitors can only
store a very limited number of presets in their memory
is a VERY valid point.
As far as KGI drivers are concerned it should be
sufficient to add a
struct kgi_timing x,y;
to ggi_mode and make drivers honour that. (They should
ofcourse still only allow valid modes.)
And we SHOULD have a configuration file like SET
suggested, only that:
* It should be ascii - not binary!
* The format should be like XFree modelines so you
just have to copy your existing values when you
change to GGI.
* It should be read by libggi, not the kernel!
* There should be a global /etc/ggi/timings.conf
and users should be able to override the values
in a ~/.ggi/timimgs.conf file (which is ok as
KGI still checks that the mode is valid)
* If an app tries to set a mode that's not listed
in the config-file, drivers will negotiate the mode
just like they do now.
* Apps should be able to override the values in the
config-files, but this can be turned off by setting
an environment variable (to protect users from braindead
binary-only apps)
We should also have a program like xvidtune (tunemode? what
does that do?) to tweak modes and write config-files for
people who don't want to calculate timings with xcalc. ;)
Comments?
//Marcus
Index:
[thread]
[date]
[subject]
[author]