From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Wed, 8 Jul 1998 15:01:36 +0200 (MET DST)

Re: set_mode complexity

Hi !

O.K. - let's put an end to this discussion ...

> 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.

Yes.

So what we should do is:

1. Write a unified monitor driver that does :

a) When a mode is asked, look it up in a modeline database.
If an exact match is found, use that mode.

b) If no exact match is found, try it using a table of
(us-based, like the current monosync driver) timings.

c) If this isn't possible either, use the multisync method.

This driver will need the following changes from the current 
source:

A) Unify the three current drivers into one new.

B) Provide a root-only programming ioctl that allows to set 
all parameters to all subdrivers. An example of this is already
there for the timelist driver, as well as the tunemode.c
application that calls it. Tunemode.c already _can_ parse
XF86Config files, it's just someone needs to fix it up a 
little.

C) Add a few additional parameters to the multisync driver 
that allow to move positioning of the sync pulse and blanking
intervals. This should use some simple approximation like
"sync at m*width+n % of the border interval" (m,n parameters).

D) Add a non-root ioctl, that allows to specify a policy
regarding the order of mode-selection and the direction
in which to tune. This is for the speed<->frequency tradeoff
cases. Note that reordering modes does not impose a
security hazard, as all modes that are active must be
safe. If they are not, root made a mistake.

> And we SHOULD have a configuration file like SET
> suggested, only that:
> * It should be ascii - not binary!

Yes.

> * The format should be like XFree modelines so you
>   just have to copy your existing values when you
>   change to GGI.

Yes.

> * It should be read by libggi, not the kernel!

It should be read and downloaded by an application that is
taylored to do this. I suggest tunemode, as it already is
there, and does mode-tweaking also, which is what this
actually is all about.
It can detect, if it runs as root and thus give more options 
in that case, while constraining itself to just changing
order for the other case. 

> * 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)

No. The user should not be able to specify timings.
He might be able to _select_ timings out of a given 
list. 

And I think an application should _not_ try to be smart
about this. This is a matter of personal preferences.

I don't care about speed too much, but I care much about
straining my eyes. Other may think different. As long as the
tuning tool is scriptable, it shouldn't be a problem to run
./low_refresh_doom instead of just doom .

> 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. ;)

*grin* Never tried ? Use timelist as a monitor driver, and it
does just what you want.

CU,Andy

-- 
Andreas Beck              |  Email :  <Andreas.Beck@ggi-project.org>