Prev: iceweasel window raised with remote open
Next: How to install Eclipse 3.5 on Debian 5 (lenny) stable release ?
From: Stanisław T. Findeisen on 13 Jan 2010 10:50
Stan Hoeppner wrote:
> Just be glad you got it working at 75 Hz. Anything above 60 Hz will eliminate
> visual flicker for most people, and anything above 70 Hz will eliminate flicker
> for all people. No human has an eye with a 70 Hz plus scan rate.

I have. :-)

>> (**) s3(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
>> (II) s3(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz)
>> (**) s3(0): Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
>> (II) s3(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz)
>> (**) s3(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
>> (II) s3(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
>
>> (**) s3(0): Default mode "1024x768": 44.9 MHz, 35.5 kHz, 87.0 Hz (I)
>> (II) s3(0): Modeline "1024x768"x87.0 44.90 1024 1032 1208 1264 768 768 776 817 interlace +hsync +vsync (35.5 kHz)
>
> You don't want to use this 87 Hz mode. It is interlaced, hence the (I). You
> will notice interline twitter and likely interlace flicker using this mode and
> it will be hard on your eyes. See: http://en.wikipedia.org/wiki/Interlace

Yeah, I just wanted to understand the pixel clock : vertical refresh rate relation. I don't think my monitor supports interlaced mode.

STF

http://eisenbits.homelinux.net/~stf/
OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A

From: Stephen Powell on 13 Jan 2010 12:00
On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> What are those sync frequency ranges?

The sync frequency ranges that the X server assumes for a
non-EDID monitor when nothing is specified for them
in the config file can be found by examining the startup messages.
Going back to your original Xorg.0.log output, they are:

(II) s3(0): Configured Monitor: Using default hsync range of 31.50-37.90 kHz
(II) s3(0): Configured Monitor: Using default vrefresh range of 50.00-70.00 Hz

As you can see, this is considerably more restrictive that the published specs
in the owners manual, which are 30-70 kHz horizontal and 50-160 Hz vertical..
Manual configuration is nearly always required to get the most out of a non-EDID
monitor. And there's no substitute for knowing what the correct specs are.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> Less??

Yes. Xorg.0.log doesn't lie. The maximum pixel clock rate supported by the
s3 driver for the Trio32/64 chipset at a color depth of 16 is 80 Mhz, which
is *less* than the video bandwidth of the monitor, which according to the
published specs in the owner's manual is 110 MHz. It's the video card that
is limiting you, not the monitor. The video card's small amount of video RAM
is what is limiting you to high color (color depth 16) instead of true color
(color depth 24). The monitor is capable of true color. And it's the video
card's maximum pixel clock rate that is limiting the maximum vertical refresh
rate that you can get out of it. By the way, the maximum pixel clock rate of
the video card is dependent in part on the color depth. Before you throttled
it back to 16-bit color depth, the maximum pixel clock rate was only 50 MHz!
Go back and check your earlier posts if you don't believe me.

If the reverse were true, you might want to throttle back your video card
to keep it from overclocking your monitor. For example, if the video card had
a maximum pixel clock rate of 150 MHz you might put this in the video device
section:

Section "Device"
Identifier "Configured Video Device"
.
.
.
DacSpeed 110
.
.
.
EndSection

This artificially restricts the video card to a maximum speed of 110 MHz
so it won't go past what your monitor can handle. Unfortunately, there
doesn't appear to be a way to specify the video bandwidth of the monitor
to the X Server, which is really how it should be done. Exceeding the
video bandwidth of the monitor causes image sharpness to suffer.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> (**) s3(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
> (II) s3(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz)
> (**) s3(0): Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
> (II) s3(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz)
> (**) s3(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
> (II) s3(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
> (**) s3(0): Default mode "1024x768": 44.9 MHz, 35.5 kHz, 87.0 Hz (I)
> (II) s3(0): Modeline "1024x768"x87.0 44.90 1024 1032 1208 1264 768 768 776 817 interlace +hsync +vsync (35.5 kHz)
>
> Why, in the log lines above, (((pixel clock rate) / ((v-res) * (h-res))) != v-refresh)?
> Here: http://en.wikipedia.org/wiki/XFree86_Modeline they say that there should be equality.
> For instance: in the 1st line, 78.8 MHz / (1024*768) > 100, but the horizontal refresh rate is less: 75 Hz.
> For instance: in the last line, 44.9 MHz / (1024*768) = 57, but the horizontal refresh rate is more: 87 Hz.

You're confusing the frame length and the resolution. They are not the same.
Let's work out the timings for a specific example. Let's use this one:

(**) s3(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
(II) s3(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz)

This is a good example because the pixel clock rate is 78.8 MHz, which is not
far from the maximum pixel clock rate (often referred to informally as
a "dot clock" rate) supported by the video card, which is 80 MHz. Let's look
at those numbers in the modeline. The first number, 78.75, is the pixel clock
rate, assumed to be megahertz. (If you round this number to three significant
digits, you get 78.8, which is what is listed in the summary line above it.
But the actual clock rate is 78.75 MHz.) The second number, 1024, is the
horizontal *resolution*. It is the number of *visible* pixels in each horizontal
line. The third number, 1040, represents the start of the horizontal sync
pulse. The fourth number, 1136, represents the end of the horizontal sync pulse.
And the fifth number, 1312, represents the end of the horizontal frame. It
is this number, the horizontal *frame length*, not 1024, the horizontal
*resolution*, that you use in your division. For example,

78,750,000 / 1312 = 60,022.865

This is the horizontal refresh rate, which rounded to three significant digits
is 60 kHz. This is within the horizontal sync frequency range of 30-70 kHz;
so we're within specs.

Continuing on, the sixth number, 768, is the vertical *resolution*. It is the
number of *visible* scan lines on the screen. The seventh number, 769,
represents the start of the vertical sync pulse. The eighth number, 772,
represents the end of the vertical sync pulse. And finally, the ninth number,
800, represents the end of the vertical frame. It is this number, the
vertical *frame length*, not 768, the vertical *resolution*, that you use
in your next division.

60,022.865 / 800 = 75.028581

This is the vertical refresh rate, which when rounded to three significant
digits yields 75.0 Hz. This is within the vertical sync frequency range of
50-160 Hz; so again we're within specs.

The above calculations are for a non-interlaced mode, which most modes are.
The last mode you cited as an example is an interlaced mode.
In an interlaced mode, the video card scans *every other*
line *every other* pass. It will scan all the odd numbered lines, then
all the even numbered lines, then go back to the odd numbered lines, etc.
87 Hz is actually the "half screen" vertical refresh rate. It's the number
of vertical scans completed in one second. But each vertical scan only
writes half of the lines. The calculations for an interlaced mode are
more complicated and I'm not going to go into details on it.
These days, many video chipsets and/or drivers don't support interlaced
modes anymore. They were a way to reduce flicker on monitors with low
video bandwidth and they have largely outlived their usefulness.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> Where do those modes come from, if there are none in the config file
> and my monitor does not support EDID?

The X server has an internal list of VESA standard video modes
that it can choose from.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> I can also see that the monitor mode I want
> (1024x768 / 94.5 Mhz / 68.677 kHz / 85 Hz from the monitor manual)
> is not on the list. Why?

I'm not sure if that exact modeline is in the X server's
database of VESA standard modelines or not. If not, there's
probably something else that is close. But even if it were,
it still wouldn't be chosen. That mode requires a pixel clock
rate of 94.5 MHz. That's above 80. Too high.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> What do those line prefixes ((--), (==), (**), (WW), (II) etc.)
> in the log stand for? I would guess (WW) stands for "warning",
> but all the rest looks like "notice"...

The Xorg.0.log file itself tells you what they mean. I quote:

Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> With this I am able to run 1024x768x16 @ 75 Hz! However, I wanted 85 Hz.

The video card's maximum pixel clock rate is too low to get a
vertical refresh rate of 85 Hz. Your monitor can do it, but the
video card cannot.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> I also tried TargetRefresh=85 but with no success.

It tried! But it couldn't find any modelines with a vertical refresh
rate of 85 Hz or higher that used a pixel clock rate of 80 MHz or lower.
75 Hz was the best it could do, and that required a pixel clock rate
of 78.75 MHz, just below the maximum.

On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
> I would say maximum pixel clock rate supported by the video card
> is 80 MHz and *that* is the limit?...

For this driver, chipset, and color depth, yes.
You are now operating at the optimum capabilities of your video
card and monitor combination. Congratulations.
I don't know about you, but my eyes cannot detect any noticeable
flicker at a 75 Hz vertical refresh rate.

Cheers,
SMP


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stanisław T. Findeisen on 13 Jan 2010 12:40
Stephen Powell wrote:
> On 2010-01-13 at 07:18:51 -0500, Stanisław T. Findeisen wrote:
>> What are those sync frequency ranges?
>
> The sync frequency ranges that the X server assumes for a
> non-EDID monitor when nothing is specified for them
> in the config file can be found by examining the startup messages.
> Going back to your original Xorg.0.log output, they are:
>
> (II) s3(0): Configured Monitor: Using default hsync range of 31.50-37.90 kHz
> (II) s3(0): Configured Monitor: Using default vrefresh range of 50.00-70.00 Hz
>
> As you can see, this is considerably more restrictive that the published specs
> in the owners manual, which are 30-70 kHz horizontal and 50-160 Hz vertical.
> Manual configuration is nearly always required to get the most out of a non-EDID
> monitor. And there's no substitute for knowing what the correct specs are.

Yeah, but what *are* those "sync frequency ranges"? Sorry I don't understand. My monitor's manual does not specify any display modes with vertical refresh rate >86Hz. Is it so, that there are "hidden modes" available that are not specified in the manual? For instance some low resolution, few colors and 160Hz vertical refresh rate?

Your help was invaluable but if you explained me this one more thing that would be even better.

> You're confusing the frame length and the resolution. They are not the same.
> Let's work out the timings for a specific example. Let's use this one:
>
> (**) s3(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
> (II) s3(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz)
>
> This is a good example because the pixel clock rate is 78.8 MHz, which is not
> far from the maximum pixel clock rate (often referred to informally as
> a "dot clock" rate) supported by the video card, which is 80 MHz. Let's look
> at those numbers in the modeline. The first number, 78.75, is the pixel clock
> rate, assumed to be megahertz. (If you round this number to three significant
> digits, you get 78.8, which is what is listed in the summary line above it.
> But the actual clock rate is 78.75 MHz.) The second number, 1024, is the
> horizontal *resolution*. It is the number of *visible* pixels in each horizontal
> line. The third number, 1040, represents the start of the horizontal sync
> pulse. The fourth number, 1136, represents the end of the horizontal sync pulse.
> And the fifth number, 1312, represents the end of the horizontal frame. It
> is this number, the horizontal *frame length*, not 1024, the horizontal
> *resolution*, that you use in your division. For example,
>
> 78,750,000 / 1312 = 60,022.865
>
> This is the horizontal refresh rate, which rounded to three significant digits
> is 60 kHz. This is within the horizontal sync frequency range of 30-70 kHz;
> so we're within specs.
>
> Continuing on, the sixth number, 768, is the vertical *resolution*. It is the
> number of *visible* scan lines on the screen. The seventh number, 769,
> represents the start of the vertical sync pulse. The eighth number, 772,
> represents the end of the vertical sync pulse. And finally, the ninth number,
> 800, represents the end of the vertical frame. It is this number, the
> vertical *frame length*, not 768, the vertical *resolution*, that you use
> in your next division.
>
> 60,022.865 / 800 = 75.028581
>
> This is the vertical refresh rate, which when rounded to three significant
> digits yields 75.0 Hz. This is within the vertical sync frequency range of
> 50-160 Hz; so again we're within specs.

Uhm. I see.

STF

http://eisenbits.homelinux.net/~stf/
OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stephen Powell on 13 Jan 2010 13:50
On 2010-01-13 at 12:34:40 -0500, Stanisław T. Findeisen wrote:
> Yeah, but what *are* those "sync frequency ranges"?
> Sorry I don't understand. My monitor's manual does not
> specify any display modes with vertical refresh rate >86Hz.
> Is it so, that there are "hidden modes" available that are
> not specified in the manual? For instance some low resolution,
> few colors and 160Hz vertical refresh rate?

I think you're confusing standard modes and physics.
A sync frequency range, horizontal or vertical, is a range
of frequencies within which the monitor is capable of
"syncing" (synchronizing). It is the range of frequencies
within which the monitor is capable of producing a stable
picture. If the monitor is "in sync", the same pixel will
be in exactly the same place on the screen, scan after scan
after scan. If the monitor is out of sync, the pixel's
position will drift from scan to scan, producing an
unstable image which may not even be recognizable.

The display modes listed in your monitor's manual are
standard display modes that the manufacturer recommends.
And they will of course be within spec. That is, those modes
will have a horizontal refresh rate that is within
the horizontal sync frequency range and a vertical refresh rate
that is within the vertical sync frequency range.
Does that mean that every video card will be capable of
displaying all of these modes? No. The limits of the video
card, such as the maximum pixel clock rate, etc., may limit
which of these standard modes can actually be displayed.

Does that
mean that the modes listed in the manual are the only modes
that will work? No. It is possible to create your own
homemade video mode. It may have an odd-ball screen resolution,
like 700x525 for example. It may have a high vertical refresh
rate. But there are trade-offs. You can't eat your cake and
have it too.

If you want a video mode with a vertical refresh rate of 85 Hz,
you can create one. But you will have to sacrifice resolution
to get it. You can't get 85 Hz vertical refresh at 1024x768
resolution with this video card. It's dot clock can't go
high enough for that.

There are a huge number of theoretically possible video modes
that can be created that are within the design limits. But
I'd stick with the standard ones if I were you. The newer
digital flat-screen monitors are generally much more fussy
about which video modes they will support than the older
analog CRT-based monitors. 75 Hz is really quite good.
Be content.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stanisław T. Findeisen on 13 Jan 2010 19:40
Thanks Stephen for great help.

STF

http://eisenbits.homelinux.net/~stf/
OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: iceweasel window raised with remote open
Next: How to install Eclipse 3.5 on Debian 5 (lenny) stable release ?