From: Salvador Eduardo Tropea (SET) <salvador@inti.gov.ar>
  To  : Emmanuel Marty , ggi-develop@eskimo.com
  Date: Wed, 8 Jul 1998 11:15:28 +0000

Re: set_mode complexity

Emmanuel Marty <core@suntech.fr> wrote:

> First of all thanks for your comments.

Ok, thank you for taking a read.
 
> > 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).

That's why I proppose a methode to make it, but outside the module 
itself. Most programs works with any video mode, only few needs to 
imposse a mode, and in this case the number of modes isn't that huge 
as you could think. As the methode I proppose will calculate these 
mode there is no problem.
 
> 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.

Nope. When a game needs a tweacked is because of the addressing mode 
of the board and not the geometry of the screen. Some code could need 
an X-mode to do some tricks enabling more than one plane at the same 
time, a negociated mode won't help at all here.
 
> 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

I'm not saying it. The modes must be calculated (with the same or 
other methode) during the installation of the module.
 
> 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.

Again: the modes must be calculated, but not each time somebody sets 
the video mode. I proppose something like a cache so we can move the 
complexity outside the module.
 
> > 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..

I don't think so. In my exprience the calibrations are individual for 
each mode you can't calibrate all at the same time. Some modes could 
be OK and others shifted to right and yet others shifted to the left. 
In my experience you must be able to calibrate the modes 
individually, there is no solution that will cover all the modes.
 
> > 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, 

Yes, it needs around 16 bytes per mode, adding more information could 
take another 16 bytes, that means less than 1Kb for 30 modes. At 
least that's what I use for the TGUI9440 chip.

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

It must be solved when you install the things, at this time the 
installation program knows the components and can calculate the 
values.
 
> > 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...

Ok, sorry, then some application does it and pass the values to the 
driver. For example: the program parses a text file and creates a 
table that's passed to the driver.
 
> > 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..

You can still supporting this interface, that isn't the point.
 
> > 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 this machine can even show something during boot. I doubt that's 
a good situation.

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

I'm not talking about this functionallity IN the driver. The driver 
just makes a call to the OS informing the problem. You can choose the 
implementation of how to solve it.
 
> > 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.

I think drivers must only make the read/write stuff plus the 
translation to the hardware specific registers, and not a complex 
task like negotiate a mode.
 
> > 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.

Think about a debugger like RHIDE, now suppose you are debugging a 
graphics mode program and you want to step in the code, is very 
annoying when the time to switch from text to graphics mode is huge.

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

The adjust are performed making changes like the position of the Sync 
pulse inside the blank area. This adjust MUST be done by hand and the 
result MUST be stored somewhere because is valid for this mode and 
for this monitor and for this board.

> Tweaking
> syncs, starts etc from the output of the generation routine is the
> same.

No because it will propagate the adjust to other modes.
 
> > 4) The user could create new modes even when no program asked for
> > this mode.
> 
> ..What for?

To offer this mode to the applications as preffered video modes.
 
> > 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.

Greetings, SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft@usa.net set@computer.org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013