Content deleted Content added
Citation bot (talk | contribs) Add: date. | Use this bot. Report bugs. | Suggested by Abductive | #UCB_webform 35/373 |
m comma |
||
Line 30:
In the world of [[Unix]] machines and operating systems, such conveniences were usually eschewed in favor of directly manipulating the hardware settings. This manipulation was far more flexible in that any resolution, color depth and refresh rate was attainable – limited only by the memory available to the framebuffer.
An unfortunate side-effect of this method was that the [[display device]] could be driven beyond its capabilities. In some cases, this resulted in hardware damage to the display.<ref>http://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/overd.html XFree86 Video Timings HOWTO: Overdriving Your Monitor</ref> More commonly, it simply produced garbled and unusable output. Modern CRT monitors fix this problem through the introduction of protection circuitry. When the display mode is changed, the monitor attempts to obtain a signal lock on the new refresh frequency. If the monitor is unable to obtain a signal lock, or if the signal is outside the range of its design limitations, the monitor will ignore the framebuffer signal and possibly present the user with an error message.
LCD monitors tend to contain similar protection circuitry, but for different reasons. Since the LCD must digitally sample the display signal (thereby emulating an electron beam), any signal that is out of range cannot be physically displayed on the monitor.
| |||