CVT reduced blanking.

[Luc Verhaegen]

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: ***@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.

[stuart kreitman]

Post by Luc Verhaegen
https://bugs.freedesktop.org/show_bug.cgi?id=5153

COOL!

Post by Luc Verhaegen
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).
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.

Thank you for defining the technology before launching into it.

Post by Luc Verhaegen
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?

The question begs a EE with experience designing or analyzing CRT
circuitry. If we guess
wrong, we'll hurt those folks who can least afford damage to their
equipment.

OTOH, too-fast dot clocks have been the cause of damage, not too-slow.

Post by Luc Verhaegen
I have two aging monitors here who are handling reduced blanking quite
- 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 much continuous testing are you willing to do? Maybe take off the
plastic and see if something
starts glowing or smoking in 15 to 60 minutes?

Post by Luc Verhaegen
* 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.

um, I'll try to dig this up.

Post by Luc Verhaegen
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,

I'd like to see a much wider body of experiment before accepting this as
harmless.

Post by Luc Verhaegen
an option is not added, etc, and that i can plainly commit the cvt
generator without the danger of breaking anything else :)
Luc Verhaegen.
_______________________________________________
xorg mailing list
http://lists.freedesktop.org/mailman/listinfo/xorg

[Luc Verhaegen]

Post by stuart kreitman
The question begs a EE with experience designing or analyzing CRT
circuitry. If we guess wrong, we'll hurt those folks who can least
afford damage to their equipment.
OTOH, too-fast dot clocks have been the cause of damage, not too-slow.
How much continuous testing are you willing to do? Maybe take off the
plastic and see if something
starts glowing or smoking in 15 to 60 minutes?
um, I'll try to dig this up.
I'd like to see a much wider body of experiment before accepting this as
harmless.

I'll be quite happy to run a reduced blanking mode on that 17"er all day
long. I'm sure it'll hold up nicely. The sound it produces is the same
as with the normal mode, you just get the slight ghost image, which you
can quite effectively shrink and grow by shifting the image. I'm used to
throwing bad modes and unstable dotclock pll settings at this CRT and
am quite comfortable with that. Compared to that, this wrapping feels
very benign.

If you want to try it yourself:
# 1280x1024 59.79 Hz (CVT 1.31M4-R) hsync: 63.02 kHz; pclk: 90.75 MHz
Modeline "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 +hsync -vsync

Currently, the mode validation code doesn't really check blanking, and
thus happily accepted modes with narrow blanking. The "treeside" patch
on the bugzilla adds the check for 25% (horizontal) blanking and refuses
lower when no reducing blanking is used and the blanking isn't exactly
160 clocks. And then only accepts it when the ReducedBlanking option is
set.

Luc Verhaegen.

[Benjamin Herrenschmidt]

Post by Luc Verhaegen
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?

All panels I know with a high enough resolution require reduced
blanking... I would suggest using it when we know we are dealing with a
flat panel.

Post by Luc Verhaegen
* 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.

Your DVI equipped CRT is probably just using the analog signals out of
the DVI connector, thus it's still analog not digital.

Post by Luc Verhaegen
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.

Reduced blanking is only useful for large panels (above 1600x1200
typically), I doubt those lack DVI.

Post by Luc Verhaegen
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)

And lots of monitors, even modern ones, don't implement the extended
EDID anyway.

Post by Luc Verhaegen
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.

I would keep it for panels. We definitely need to extended the mode
validation API to get more infos from the driver. Typically, drivers
often have ways to know that they are dealing with a flat panel of size
X,Y, even when lacking EDID, in which case CVT is the right way to pick
a mode. In some case, they have no such info but they do still know
wether they "detected" something on an analog connector vs. a digital
connector.

Or do we have a single case of CRT (or analog panel) where reduced
blanking is actually useful ?

Ben,

[Luc Verhaegen]

Post by Benjamin Herrenschmidt

Post by Luc Verhaegen
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?

All panels I know with a high enough resolution require reduced
blanking... I would suggest using it when we know we are dealing with a
flat panel.

But when do we know wether we are dealing with a panel. That's what this
mail is all about.

Post by Benjamin Herrenschmidt
Your DVI equipped CRT is probably just using the analog signals out of
the DVI connector, thus it's still analog not digital.

DVI connected CRTs do exist. They're rare, but imho there's no reason
why they too can't be digitally connected.

This one is an iiyama vision master pro 453, (ha-901d). One analog
input, one DVI-D.

Other CRTs which i know have DVI: IBM P260 and P275 and the NEC FP
1375x.

Post by Benjamin Herrenschmidt
Reduced blanking is only useful for large panels (above 1600x1200
typically), I doubt those lack DVI.
And lots of monitors, even modern ones, don't implement the extended
EDID anyway.
I would keep it for panels. We definitely need to extended the mode
validation API to get more infos from the driver. Typically, drivers
often have ways to know that they are dealing with a flat panel of size
X,Y, even when lacking EDID, in which case CVT is the right way to pick
a mode. In some case, they have no such info but they do still know
wether they "detected" something on an analog connector vs. a digital
connector.
Or do we have a single case of CRT (or analog panel) where reduced
blanking is actually useful ?
Ben,

I don't know, i don't have even an analogly connected panel. If analog
panels handle reduced anyway, then it certainly shouldn't be disallowed
for them either.

Luc Verhaegen.

[Benjamin Herrenschmidt]

Post by Luc Verhaegen
DVI connected CRTs do exist. They're rare, but imho there's no reason
why they too can't be digitally connected.
This one is an iiyama vision master pro 453, (ha-901d). One analog
input, one DVI-D.
Other CRTs which i know have DVI: IBM P260 and P275 and the NEC FP
1375x.

All the IBM ones I have seen at work have a DVI connector that only
carries the analog signal. I yet have to see a single CRT that uses the
digital signals (I didn't say there is none, I'm just saying that it's
easy to be confused as it's a DVI connector but it only really carries
analog signaling in most cases).

Post by Luc Verhaegen
I don't know, i don't have even an analogly connected panel. If analog
panels handle reduced anyway, then it certainly shouldn't be disallowed
for them either.

Well, I would suggest for now that you provide a way (flag or whatever)
for the driver to inform the mode calculation stuff that it knows for
sure it's a digitally connected display (some have ways to detect it).
In absence of that, don't allow CVT unless it's explicitely enabled in
the config file.

Ben.

[Luc Verhaegen]

Post by Benjamin Herrenschmidt
All the IBM ones I have seen at work have a DVI connector that only
carries the analog signal. I yet have to see a single CRT that uses the
digital signals (I didn't say there is none, I'm just saying that it's
easy to be confused as it's a DVI connector but it only really carries
analog signaling in most cases).

You're right about the p260/p275. That's pretty nasty. I would've
expected your employer to not be pulling that kind of tricks.

Same thing for the nec one. bleh.

This iiyama one is the real thing though. Limited to ***@85Hz too
because of it (analog is limited by the bandwidth of the monitor itself).
Sadly, since i'm using nothing but unichromes currently, the dvi link is
not in use and i need a secondary monitor (that 17"er) to do any
testing.

When i bought that iiyama, i was convinced that dvi was the way to go,
even for CRTs. But if other manufacturers tricked customers by just
providing a DVI-A (or a deprecated I) connection, then i see why this
didn't happen even on high end CRTs. 5y on, i'm amazed that this device
now turns out to be some sort of unicorn.

Post by Benjamin Herrenschmidt
Well, I would suggest for now that you provide a way (flag or whatever)
for the driver to inform the mode calculation stuff that it knows for
sure it's a digitally connected display (some have ways to detect it).
In absence of that, don't allow CVT unless it's explicitely enabled in
the config file.
Ben.

There is no flag needed. If we scrap modes on HBlank < 25% then we can
easily pick out those with 160clocks hblank, which are the CVT reduced
ones.

The code that currently sits in the bugzilla does all that and
implements Option "ReducedBlanking" <Bool> for the "Monitor" Section.

I'm going to repeat some pros/cons for limiting it:
- There are worries about possible damage on CRTs, but here those don't
seem to care much.
- Blanking was never really checked before.
- I'm not at all happy with a .conf option that requires a server
restart and user intervention. And i'm sure many will agree.
- A blacklist on the digital bit should be easy to implement, as
there seems to be only one entry currently.
- What about analogly connected panels? Do we really want to deny
reduced modes there? Or is the native mode at 60Hz CVT always
considered good enough? Can anyone verify that those tend to accept
reduced modes too, because i'd like to know.

My guess is that the conclusion will be:
- MonPtr->reducedblanking should be added (in patch already).
- Monitor Section Option "ReducedBlanking" should be added (in patch
already).
- Use edids digital bit to set the same, with a blacklist containing at
least: Manufacturer: IVM Model: 1930. There will likely CRTs which have
bad edid blocks too.

Luc Verhaegen.