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]