CVT reduced blanking.
Luc Verhaegen
libv at skynet.be
Mon Dec 26 08:06:48 PST 2005
I've stuck a cvt modeline generator up the bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=5153
It's based on the VESA spreadsheet and generates the same results, but
in proper xorg.conf form (the generator itself includes some xf86Mode.c
code and uses DisplayModeRec internally).
I do have some questions about what to do with reduced blanking:
Reduced blanking has been created to save bandwidth on panel displays,
where the sync and blanking may be reduced as there's no beam that has
to be repositioned. WWhat this means is that you can display the same
resolution at the same frequency while using much less bandwidth and
thus a lower dotclock.
For instance: 1280x1024 at 60Hz uses a 90.75Mhz dotclock reduced versus a
109.00Mhz one (normal). A real lifesaver when using DVI, which is
limited to 165Mhz (single link).
The question i have is, are we going to allow reduced modes to be set at
all times and how are we going to limit them otherwise?
* Will reduced blanking damage CRTs?
I have two aging monitors here who are handling reduced blanking quite
well:
- a 4y old flat 19"er: This one has the area which it can't handle
bunched together. I'm able to shift the display to either side and
display that edge properly, but this only increases the bunching at the
other edge.
- an 8y old round 17": this one wraps the unhandled area over, producing
some sort of ghost image at both sides of the screen.
With these two monitors, nothing seems to point at long term damage, at
least for short term use. So the likelyhood of damage seems pretty
small.
* How are we going to limit reduced blanking modes?
Reduced blanking can be easily detected from the modeline. If HBlank is
less than 1/4th of HTotal, then the blanking is bound to be too narrow.
If that blanking then measures exactly 160 dotclocks, then this is a CVT
reduced blanking mode.
I've taken the liberty (in the patch) to add Option "ReducedBlanking"
<Bool> to the monitor code (in the bugzilla patches). This was to find
out what server side support was needed and for testing. Option parsing
was added to configMonitor (xf86Config.c), a reducedblanking field was
added to (the end of) MonRec (xf86str.h) and the blanking check was
added to xf86CheckModeForMonitor (xf86Mode.c)
If we want to depend on options, then the above is just dandy. But the
future of X is not in a static xorg.conf and server restarts. So we
should be able to get this information from EDID (DDC) which is where
the problems start.
There's a digital bit in edid, but my DVI equipped CRT bunches the edges
together. So we will need at least a CRT blacklist for this. This also
leaves out the DVI-less panels that are sold en masse, my guess is that
they can handle reduced blanking quite well. So the digital bit seems
useless for this.
In the vesa VTB-EXT for EDID, there seems to be some hints as to wether
reduced blanking is supported. This, sadly, is when CVT modes are
listed, describing which modes the given monitor supports, which then
doesn't require the use of modelines :) (see bugzilla #5386)
If anyone has any idea as to how we can find out wether reduced
blanking is possible or not from the edid block, please speak up. I
don't have access to the EDID standard document which is afaik still not
freely available, so there might be some bit in EDID where this is
flagged which i'm not aware of.
My opinion though, is that reduced blanking should be plainly accepted.
It doesn't seem to cause damage, so there's nothing stopping the user
from playing with this. This also means that MonRec remains untouched,
an option is not added, etc, and that i can plainly commit the cvt
generator without the danger of breaking anything else :)
Luc Verhaegen.
More information about the xorg
mailing list