CVT reduced blanking.

[stuart kreitman]

Luc Verhaegen wrote:
> I've stuck a cvt modeline generator up the bugzilla: 
> https://bugs.freedesktop.org/show_bug.cgi?id=5153
>   
COOL!
> 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.
>   
Thank you for defining the technology before launching into it.
> 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?
>   
The question begs a EE with experience designing or analyzing CRT 
circuitry. If we guess
wrong, we'll hurt those folks who can least afford damage to their 
equipment.

OTOH, too-fast dot clocks have been the cause of damage, not too-slow.
> 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 much continuous testing are you willing to do? Maybe take off the 
plastic and see if something
starts glowing or smoking in 15 to 60 minutes?

> * 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.
>   
um, I'll try to dig this up.
> 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, 
>   
I'd like to see a much wider body of experiment before accepting this as 
harmless.
> an option is not added, etc, and that i can plainly commit the cvt 
> generator without the danger of breaking anything else :)
>
> Luc Verhaegen.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>