CVT reduced blanking.

Luc Verhaegen libv at skynet.be
Mon Dec 26 10:45:38 PST 2005


On Mon, Dec 26, 2005 at 09:12:50AM -0800, stuart kreitman wrote:
> 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.
>
> 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?
> 
> um, I'll try to dig this up.
>
> I'd like to see a much wider body of experiment before accepting this as
> harmless.

I'll be quite happy to run a reduced blanking mode on that 17"er all day 
long. I'm sure it'll hold up nicely. The sound it produces is the same 
as with the normal mode, you just get the slight ghost image, which you 
can quite effectively shrink and grow by shifting the image. I'm used to 
throwing bad modes and unstable dotclock pll settings at this CRT and 
am quite comfortable with that. Compared to that, this wrapping feels 
very benign.

If you want to try it yourself:
# 1280x1024 59.79 Hz (CVT 1.31M4-R) hsync: 63.02 kHz; pclk: 90.75 MHz
Modeline "1280x1024R"   90.75  1280 1328 1360 1440  1024 1027 1034 1054 +hsync -vsync

Currently, the mode validation code doesn't really check blanking, and 
thus happily accepted modes with narrow blanking. The "treeside" patch 
on the bugzilla adds the check for 25% (horizontal) blanking and refuses 
lower when no reducing blanking is used and the blanking isn't exactly 
160 clocks. And then only accepts it when the ReducedBlanking option is 
set.

Luc Verhaegen.



More information about the xorg mailing list