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