l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2002 Sep 05 18:21

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Re: vox-tech digest, Vol 1 #417 - 1 msg
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Re: vox-tech digest, Vol 1 #417 - 1 msg



Quoting Peter Jay Salzman (p@dirac.org):

> 1. try raising the maximum vertrefresh rate in the monitor section of
>    your XF86Config-4 file.  i wouldn't push it past 10% of the current
>    max value.

This is a conservative approach that will pretty much always keep you
out of trouble.  But I thought I'd try to add some historical
perspective:

Way back when, analogue monitors (VGA and improvements thereof) started
out doing maybe three or four fixed frequency combinations -- "detent" 
resolutions, if you will.  Soon thereafter, NEC introduced the original
Multisync series of monitors, and everyone else cloned the concept.  The
Multisyncs automatically locked onto any incoming video signal within
its horizontal and vertical frequency limits.  And they had really good 
protection circuitry to blank the display any time you fed them signals 
outside those limits.

Which was very nice.  The temptation was to assume that _all_ monitors
were that well built, and that capable.  Unfortunately, there were lots
of existing, older monitors that weren't.  With a Multisync (and
imitators), you could throw caution to the wind and just feed it the
fastest signal you _hoped_ it would autosync onto.  If you got blank
video, it meant you were overreaching, and needed to step down a bit.
The moment you dropped low enough, it worked.

With a lesser (typically much older) monitor, it was possible to feed it
a signal that either it couldn't sync to but kept trying, or (as claimed
by some) that produced a picture but stressed the monitor to eventual
failure.   I have extreme doubts about the latter:  Over a decade of
XFree86 setup work, I never once had a monitor burn out on a successful
sync.  In my experience, when you fired up the X11 session to test your 
configuration work, if you immediately (within a minute or two) killed
the X server if you heard a monitor whine or saw it fail to sync, then
you would never hurt it.

And it has basically been something over a decade since multisynchronous 
monitors basically totally supplanted the vulnerable kind.  So, within 
reason, the "You could destroy your monitor" warning to be cautious
about frequency limits _should_ be obsolete.

Yet, caution on this point persists.  Why?  Because:

1.  The day you stop advising caution, Great Murphy will send you
someone with an antique, vulnerable, heap of junk monitor -- leaving you
at the end of the day with blame, an invoice, a lawsuit threat, or like
that.

2.  Even if you explain the bit about "Hit Ctrl-Alt-Bkspc instantly if
you either hear a high-pitched whine or you fail to get a stable image" 
slowly and in very small words, _someone_ will fail to get it, and again
you can be the goat.

So, every time I'm tempted to say "Screw the HorizSync and VertRefresh
safeguards; set them deliberately wide", expediency makes me bite my
tongue.

>    Section "Monitor"
>       Identifier      "Miserable Monitor"
>       HorizSync       30-84
>       VertRefresh     50-75
>       Option          "DPMS"
>    EndSection
> 
> 
> who called it "miserable monitor"?  if the monitor is truly this
> miserable, there's much you can do about it.  your vertical refresh
> rate is surprisingly low for a newish monitor.   as a first line of
> attack, i would do some websearching and make sure these numbers are
> correct. 

Second the motion.  Sounds like a logical suspect.

-- 
Cheers,            There are only 10 types of people in this world -- 
Rick Moen          those who understand binary arithmetic and those who don't.
rick@linuxmafia.com
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.