Re: DDC1: Good Stuff.

[Filip S. <fs...@st...>]

On Wed, 31 Jul 2002, Brian S. Julin wrote:

>
> On Tue, 30 Jul 2002, Filip Spacek wrote:
> > I've done some researching and the 'math' is actually well defined (at
> > least for newer monitors). It is defined in "VESA, Generalized Timing
> > Formula Standard - GTF, Version 1.0, December 18, 1996". Unfortunately
> > this document is not publicly available.
>
> Yeah, I remember that, the bastards :-)
>
> > Given your success so far, maybe
> > you might be able to obtain it? VESA provides only a sample Excel
> > spreadsheet with the calculations that need to be done. Unfortunately they
> > are not really trivial and a spreadsheet is probably the worst method of
> > distributing mathematical formulas. As if that wasn't bad enough all math
> > is done in floating point (a no-no in kernel), so it will require some
> > tweaking to get the the same results using integer math. Intersted people
> > can look at
> >
> > ftp://ftp.vesa.org/pub/GTF/GTF_V1R1.xls
> >
>
> Does anyone have an idea as to the date at which the original multisync code
> disappeared?  I can look around and see if I tucked a copy away somewhere.
> IIRC this code worked fine and I see no reason to change the way we were doing
> things in this area.  (Other than a total rewrite to make it milk the hardware
> to it's fullest extent, but that turns out to require some pretty fancy
> linear programming techniques, which are best keft to userspace.)  The
> old code had one drawback which prevented it from correctly negotiating
> anything more than pixeldoubled/scandoubled modes, but other than that
> it worked great.


I found some code in the ggi 0.0.9 release (on ggi's ftp site).

However, the beauty of GTF is that it would actually allow us to milk the
hardware to the max since GTF actually has 3 formulas depending on the
starting parameter: vertical rate, horizontal rate and pixel clock. So we
could really take advantage of the mode negotiation loop. During the
TC_PROPOSE phase, the monitor driver would get a timing using the maximum
horizontal and vertical rate and it would use the better of the two. This
would probably create way too high pixel clock so during the TC_LOWER
phase the clock driver would cap that off to what the chipset can handle
and finally the monitor driver would recalculate the timings using this
dot clock.

Another reason for using GTF is that modern monitors are actually
officialy "GTF Compliant" so the formula would in those cases produce
pretty ideal timings.

I've been making my way through the spreadsheet but it is a slow going. It
should be possible though (the proof of it being the modeline generator
available at http://www.cs.odu.edu/~olson/linux/gtf.c)

-Filip