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:
July 21: Defensive computing: Information security for individuals
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2002 Sep 05 18:46

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




i never knew this!

rick, perhaps you should contact ESR and ask him to include this email,
nearly verbatim, to the video mode timing howto?  i sure could've
benefited knowing this stuff before.

i've been writing home-brewed video modes for years now to squeeze
performance out of my video cards for gaming, but didn't know any of
this.  i just assumed that if something didn't look or sound right,
ctl-alt-backspace would save me.  guess i didn't need saving all along.

btw, how much of this stuff is true for tft's or laptops?  i'm always
worried about laptops because half the time i can't find the power
switch, let alone ctl-alt-backspace.  do low-space items like these also
carry protection circuitry?

pete



begin Rick Moen <rick@linuxmafia.com> 
> 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

-- 
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
_______________________________________________
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:
O'Reilly and Associates
For numerous book donations.