CVT reduced blanking.

[Benjamin Herrenschmidt]

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

All panels I know with a high enough resolution require reduced
blanking... I would suggest using it when we know we are dealing with a
flat panel.

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

Your DVI equipped CRT is probably just using the analog signals out of
the DVI connector, thus it's still analog not digital.

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

Reduced blanking is only useful for large panels (above 1600x1200
typically), I doubt those lack DVI.

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

And lots of monitors, even modern ones, don't implement the extended
EDID anyway.

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

I would keep it for panels. We definitely need to extended the mode
validation API to get more infos from the driver. Typically, drivers
often have ways to know that they are dealing with a flat panel of size
X,Y, even when lacking EDID, in which case CVT is the right way to pick
a mode. In some case, they have no such info but they do still know
wether they "detected" something on an analog connector vs. a digital
connector.

Or do we have a single case of CRT (or analog panel) where reduced
blanking is actually useful ?

Ben,