CVT reduced blanking.

[Luc Verhaegen]

I've stuck a cvt modeline generator up the bugzilla: 
https://bugs.freedesktop.org/show_bug.cgi?id=5153

It's based on the VESA spreadsheet and generates the same results, but 
in proper xorg.conf form (the generator itself includes some xf86Mode.c 
code and uses DisplayModeRec internally).

I do have some questions about what to do with reduced blanking:

Reduced blanking has been created to save bandwidth on panel displays, 
where the sync and blanking may be reduced as there's no beam that has 
to be repositioned. WWhat this means is that you can display the same 
resolution at the same frequency while using much less bandwidth and 
thus a lower dotclock.

For instance: 1280x1024 at 60Hz uses a 90.75Mhz dotclock reduced versus a 
109.00Mhz one (normal). A real lifesaver when using DVI, which is 
limited to 165Mhz (single link).

The question i have is, are we going to allow reduced modes to be set at 
all times and how are we going to limit them otherwise?

* Will reduced blanking damage CRTs?

I have two aging monitors here who are handling reduced blanking quite 
well:
- a 4y old flat 19"er: This one has the area which it can't handle
bunched together. I'm able to shift the display to either side and 
display that edge properly, but this only increases the bunching at the 
other edge.
- an 8y old round 17": this one wraps the unhandled area over, producing 
some sort of ghost image at both sides of the screen.

With these two monitors, nothing seems to point at long term damage, at 
least for short term use. So the likelyhood of damage seems pretty 
small.

* How are we going to limit reduced blanking modes?

Reduced blanking can be easily detected from the modeline. If HBlank is 
less than 1/4th of HTotal, then the blanking is bound to be too narrow. 
If that blanking then measures exactly 160 dotclocks, then this is a CVT 
reduced blanking mode.

I've taken the liberty (in the patch) to add Option "ReducedBlanking" 
<Bool> to the monitor code (in the bugzilla patches). This was to find 
out what server side support was needed and for testing. Option parsing 
was added to configMonitor (xf86Config.c), a reducedblanking field was 
added to (the end of) MonRec (xf86str.h) and the blanking check was 
added to xf86CheckModeForMonitor (xf86Mode.c)

If we want to depend on options, then the above is just dandy. But the 
future of X is not in a static xorg.conf and server restarts. So we 
should be able to get this information from EDID (DDC) which is where 
the problems start.

There's a digital bit in edid, but my DVI equipped CRT bunches the edges 
together. So we will need at least a CRT blacklist for this. This also 
leaves out the DVI-less panels that are sold en masse, my guess is that 
they can handle reduced blanking quite well. So the digital bit seems 
useless for this.

In the vesa VTB-EXT for EDID, there seems to be some hints as to wether 
reduced blanking is supported. This, sadly, is when CVT modes are 
listed, describing which modes the given monitor supports, which then 
doesn't require the use of modelines :) (see bugzilla #5386)

If anyone has any idea as to how we can find out wether reduced 
blanking is possible or not from the edid block, please speak up. I 
don't have access to the EDID standard document which is afaik still not 
freely available, so there might be some bit in EDID where this is 
flagged which i'm not aware of.

My opinion though, is that reduced blanking should be plainly accepted.
It doesn't seem to cause damage, so there's nothing stopping the user 
from playing with this. This also means that MonRec remains untouched, 
an option is not added, etc, and that i can plainly commit the cvt 
generator without the danger of breaking anything else :)

Luc Verhaegen.