From: Emmanuel Marty <core@suntech.fr>
  To  : ggi-develop@eskimo.com
  Date: Tue, 07 Jul 1998 22:31:46 +0000

Re: set_mode complexity

Salvador Eduardo Tropea (SET) wrote:

> Hello all:
>
>   I'm new to this group so forgive my ignorance. I just discovered
> the
> GGI/KGI project some days ago.

Hi,

First of all thanks for your comments.

> 1) I think nobody needs a display driver that supports any propposed
> mode. I
> think most of the applications can work with a list of common modes.
> Even when
> some program could need it we don't need to provide such a facilitie
> in the
> module (I explain it latter).

Well, true, for "common use" on x86 platforms, we'd just need a
precomputed list of modes and off we go, that's how windoze drivers
are designed for example. The board tells what modes it can do,
and constraints the caller to use them.

However, this is a very PC-centric and graphical-desktop centric
usage. A Macintosh has different modes (I don't remember a
precise one at the moment, but you can expect things like
1184x960 or something).

Then, we really want GGI to be used by game developers, etc,
who often use tweaked resolutions in order to exploit some hardware
capability or just use the best mode suited for them.

All drivers can now do a lot of unusual modes, I think it would
be silly to trash that. For example, the GGI console starts in 720x480
with 9 pixels wide fonts, more precise than 640x480 with 8 pixel
wide ones..

If we did input register data lists for every mode for every chipset supported

by the driver, we'd maybe end up with a bigger module than the current
ones with code to produce them..

Plus, how would you solve problems with monosync/multisync drivers..?
They would still have to constrain the possible displays, and this info
isn't available at driver-writing time.

> 2) What about the calibration of the mode? You can suppose that the
> video
> mode will be perfectly displayed just because you did an
> ultra-complex check
> to see if the frequencies are OK. The screen could be wrongly
> centered and
> not all the monitors can fix it, even brand new monitors have a limit
> to the
> number of modes that they can store (ViewSonic monitors stores the
> corrections for 16 modes based on the VSync/HSync values).

Well, some calibration utility should be pretty easy to write, given the
current drivers capability of programming the chip on the fly. If you
start using precomputed data, it'll be harder actually..

> So my idea is the following:
>
> 1) Put all the complex stuff *outside* the kernel module, just let
> the low
> level stuff (the one that needs access to the registers).

You'd still need to put the precomputed syncs etc in the
driver, if you multiply that by the number of modes supported times the
number of different chipsets (ie. one RAMDAC supporting max. 80 mhz,
the other 135.. real fun), that may be a severe bloat, and you
still will need code to cope with all monitors; that last bit can be
resolved at compile time too, but is it worth the work anyway?

> 2) At the installation stage when the monitor/video card are
> detected/specified the installation program calculates the most
> common modes
> (320x200 640x400 320x240 512x348 640x480 800x600 1024x768 1280x1024
> ...)

Again this is just common to the PC, and for desktop use. Modes like
720x400 or 256x240 are possible just by programming the card correctly,
would be silly not to have them..

> ) and
> stores the results in a binary file. This file is loaded by the
> driver (or if
> we really need it can be inside the module).

A driver accessing a file isn't a good idea at all...

> 3) The applications asks to the drivers a list of available modes (in
> a printer the loaded paper make it fixed, you can only change the
> resolution,
> so is a similar case). If the application finds the desired mode in
> the list
> or if the application finds a suitable mode all is solved and we jump
> to 6.

It moves some more difficulty into the application - it has to process
a list of modes, pick one, try, maybe retry.. DirectX does that and I
hate it to bits.. Currently, KGI drivers are allowed some margin so
unless you ask an unfeasible mode like 780x480, it will find the
closest/best one by itself..

> 5) A new console is oupened using a *very* simple mode, the same
> using during
> the boot process I guess. A configuration program is started in this
> console
> and calculates the parameters for the new mode.

This is completely not portable - KGI drivers are being ported
to Roadrunner and Dolphin; I don't know about the former, but the
latter doesn't even have the idea of a console.. And what if
your "very simple mode" isn't supported by the console that
you open to tell the user the mode isn't supported... etc. Then the
driver would have to implement os-specific mechanisms or so..
Plus this is not the way - a driver doesn't provide an user interface,
it just executes commands. That should happen from an userland
program controlling the driver.. Some OSes have drivers that
provide user interfaces, but their "stability" is wellknown..

> What are the advantages:
>
> 1) The modules are simpler, all the complex stuff is in the
> configuration
> program. So we gain in size.

That has to be proved.. The routine that computes the correct
syncs isn't really big. You can't move out what makes 95% of
the driver, interacting with the kernel and converting these
syncs into board-specific data and writing it into the board
registers.

> 2) The modules are faster, they only needs to set the registers with
> the
> precalculated values. So we gain in speed.

Setting a mode typically happens once during the application
life.. Once is never. Of course, setting a mode shouldn't take 20
minutes, but speed isn't an issue here; once it's set, the application
can hit the framebuffer, use accel etc, and _here_ is where
speed matters.. In calls used repeatedly.

> 3) The modes can be adjusted, that's very hard with the complex
> algorithm
> currently propposed.

How is it easier having fixed precomputed mode lists? Tweaking
syncs, starts etc from the output of the generation routine is the
same.

> 4) The user could create new modes even when no program asked for
> this mode.

..What for?

> 5) The complex stuff is optional and can be more or less complex
> because is
> in the configuration program and not in the driver. So if we discover
> a
> better methode we don't need to change all the drivers.

We don't need to change all drivers if we change the sync calculation
code either, it isn't duplicated. We need to recompile them, but that's
it.

> That's only an idea.

And thanks for expressing it..

--
Emmanuel