Re: [AD] fbcon patch, for mode timings

[George Foot <mert0407@xxxxxxxxxx>]

[Cc to postmaster@xxxxxxxxxx to help with debugging my mail
problems -- please remove the Cc in your replies and Cc to me
instead]

On Fri, Jul 23, 1999 at 07:16:02PM +0100, Shawn Hargreaves wrote:
> George Foot <mert0407@xxxxxxxxxx> writes:
> > This patch makes the fbcon driver able to tweak the mode timings
> > when it sets a video mode.
> 
> Excellent! I take it that you got fbset working, then?

No.  Grzegorz sent me a copy of his fb.modes file, but mostly
I've been testing settings converted from my X modelines.

> > I think I'm going to make the setup program auto-convert information 
> > from fb.modes, maybe provide a dotclock probing system, and probably 
> > provide an equivalent of xvidtune.
> 
> How hard would it be to make Allegro read fb.modes directly at runtime?

I'm doing that, as one option, but I don't have any
documentation on the file format here at the moment and some of
the fields I need aren't filled in in the examples Grzegorz gave
me.  In particular, the vmode field which can be normal,
interlaced or doublescan.

Maybe we can detect that though -- if the vsync rate would be
astronomical, we're probably meant to be doublescanning, and if
it would be very low we're probably meant to be interlacing.
I'm getting worried that we'll need to know some information
about the person's monitor before we can safely guess at this
sort of thing, though.

> I 
> think that would be nicer than having to duplicate that information in 
> both config files, and this way people would only ever have to tune their 
> system once (if you wrote an xvidtune equivalent, it would affect fbset 
> and any other fbcon programs as well as just Allegro).

I'm comfortable parsing the file, but not so comfortable writing
it out again afterwards.  I also don't fully understand it; it
seems to include the colour depth and virtual resolution in the
mode description, probably because each mode in the file is an
argument you can pass to fbset and this information is needed
when setting modes that way, but since all I'm doing is sorting
out the timings I'd think that I'd need to write out several
records, one for each depth.  I'm really not sure.

I've just about finished modifying the setup program, so the
best thing is probably for me to complete this and upload it,
then let someone with more documentation make whatever changes
are needed.

In the system I'm implementing, the driver looks for data about
the resolution requested.  If it's not found, it tries to use
the data for the mode with closest greater horizontal resolution
and closest greater vertical resolution, and increases the
margin sizes to reduce the overall displayed resolution.  That's
the neatest way I could see of minimising the number of modes
that need exact settings to be provided.  Another option is not
to alter the margins, but that changes the sync frequencies
(increasing them) which seems a less reliable thing to do -- on
old hardware, anyway.  Or perhaps we could just add all this
time into the sync phase, so the margins stay roughly the same.

Maybe someone who knows more about video hardware can comment --
and perhaps describe or implement an algorithm to guess
appropriate timings automatically?  The only thing I don't know
here is how I should distribute the retrace time -- how much of
it needs to be in the sync phase and what sort of minimums there
are on the margins.

-- 
George