4

When I first got into using Linux around the turn of the millennium, XFree86 was still in use, with the associated use of the xf86config command to manually set everything up, and the warning that entering incorrect sync values could permanently damage the monitor stuck with me.

This answer explains the mechanism by which that happens, and points out that monitor designs derived from TV designs should be protected from that problem by the circuitry needed to safely deal with noisy TV signals, but that left me wondering.

How common was it to use a vulnerable design at various points along the timeline?

(And, as a subset of that question, given how ludicrous an idea it is for a modern LCD to fry itself in response to invalid input, at what point did it become safe to assume that all newly manufactured displays had such protection? It makes no sense for LCDs to be vulnerable to an artifact of how CRTs work, but did CRT monitor manufacturers manage to reach that point before LCDs took over?)

  • 2
    Was there ever a point in time where one could assume that a cheap analog monitor would have this kind of protection? To be on the safe side, I'd have never assumed that. OTOH, I'd have assumed that more expensive MultiSync monitors would have this kind of protection. (And BTW, monitors are not the only thing you can damage using unsafe frequencies; I fried a TV encoder chip on a graphics card in this way). – dirkt Mar 7 '20 at 8:13
  • I said become safe to assume that a monitor ... (omitting the "analog") because I was wondering whether the "show an 'out of sync' OSD message" approach managed to reach all CRT monitor models before LCDs took over. I know that, back around 2002 or 2003, I bought a new 17" Viewsonic that had that safety feature and I was just a teenager trying to get the best deal on his first brand-new not-for-the-whole-family computer then. (i.e. Obviously, you can trust a modern LCD to not fry itself if given an out-of-sync signal... but when did that become universal?) – ssokolow Mar 7 '20 at 8:20
  • 2
    Not all LCDs are immune to the effects of bad input. Many LCDs reverse their drive phase once per frame, and may be damaged--even if code doesn't mess with sync--if code alternates for an extended period of time between showing a region as white pixels and dark pixels on alternate frames. Even some newer LCDs may be damaged if code uses a pattern of light and dark pixels that coincides with whatever pattern the LCD uses to reverse polarity. – supercat Mar 8 '20 at 20:16
  • @supercat You're saying there's a killer poke in some LCDs that's purely a function of what's displayed on screen? In this era of web applications, that's horrifying. – ssokolow Mar 10 '20 at 1:46
  • @ssokolow: The effects are slow, and as far as I've accidentally had them run, reversible; in the most terrifying example, I left a pad pattern feeding a display during my lunch hour. I don't remember exactly how quickly it recovered, but it was a few minutes before I it was apparent the display would be fully usable again, and even the next day there was still ghosting. My understanding of the technology is that had things gone on long enough there would have been a permanent ghost image, but I'm not sure how long that would have taken. – supercat Mar 10 '20 at 2:40
1

For a monitor to maintain picture size and centering over a range of sync rates, it would need to sense what sync rate it was being fed. A simple fixed-frequency monitor might feed the deflection signals with a fixed-amplitude signal without regard for frequency or any attempt to monitor the changing current in the deflection coils, but a multi-frequency monitor would need to adjust the drive waveform either in response to either the frequency or the peak coil current. Once one has sensing for either of those things, very little additional circuitry is needed to make things fail-safe.

Further, a common difficulty in designing a good multi-frequency monitor is maintaining linearity over the full range of sweep frequencies. Using a microcontroller to determine how drive waveforms need to be adjusted at different frequencies is simpler than trying to do as good a job with analog electronics. Even if the microcontroller has no on-screen display and simply operates a few digital-to-analog converters to produce control voltages, it can easily incorporate fail-safe shutdown logic at essentially no extra cost.

0

Bad sync signal stopped being an issue when NEC introduced MultiSync, around 1989. Other monitor makers followed soon afterwards.

  • 2
    My understanding is that MultiSync and other multiscan technologies are about supporting multiple resolutions but don't inherently guarantee failsafe behaviour in the presence of an out-of-spec sync signal. – ssokolow Mar 13 '20 at 12:39
  • While I generally agree with Lior, their comment is stated too absolutely. I can well imagine inexperienced engineer(s) at a low margin company not knowing they should bounds-check their inputs. It is also possible they did bounds-check, but didn't envision the wide variety of synch combinations and refresh rates their monitor might receive. – RichF Apr 11 '20 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.