Prev: iceweasel window raised with remote open
Next: How to install Eclipse 3.5 on Debian 5 (lenny) stable release ?
From: Stephen Powell on 15 Jan 2010 10:00
On 2010-01-13 at 19:38:33 -0500, Stanisław T. Findeisen wrote:
> Thanks Stephen for great help.

You're welcome! I hope you get much trouble-free use out of your new system.


--
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 16 Jan 2010 11:40
I need to correct an earlier post.

On 2010-01-13 at 11:57:48 -0500, Stephen Powell wrote:
> 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.

Oops, that is now no longer true! There didn't used to be a way,
but now there is.

Option "MaxClock" "110"

in the monitor section is the way to do it. In your current
setup, it doesn't really matter because the video card's
maximum dot clock rate is lower than the monitor's video bandwidth.
Therefore, it is impossible to exceed the monitor's video bandwidth.
But if you ever use this monitor with another video card, one whose
dot clock can go faster than 110 MHz, that is the "right" way to make
sure that you don't overclock your monitor, rather than overriding
the DacSpeed in the video card section. There is a "MinClock"
setting too. According to the man page for xorg.conf, this
value is to be specified in kHz, but I think that that is probably
a mis-print. Dot clock values have always been specified in MHz.

In summary, the governing equations for CRT monitors are as
follows:

horizontal_frame_length * vertical_frame_length * vertical_refresh_rate = pixel_clock_rate

and

horizontal_frame_length * horizontal_refresh_rate = pixel_clock_rate

(This is assuming a non-interlaced mode.) From these two equations,
a third equation can be derived, which is

vertical_frame_length * vertical_refresh_rate = horizontal_refresh_rate

These govern all the trade-offs in video modes. As you can see from
the first equation, if you want a higher vertical refresh rate, you must
either use a higher pixel clock rate or a lower resolution. These are
the laws of physics and you can't change them.

Also, after re-reading the series of posts, I now see why you said

> Less??

That first time. You're right, the correct word in that sentence was "more".
Good luck and best wishes.


--
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 19 Jan 2010 23:20
Mr. Findeisen, I just realized something.

On 2010-01-13 at 11:57:48 -0500 Stephen Powell wrote:
> 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.

Maybe I spoke too soon. It's true that some video drivers and/or
chipsets no longer support interlaced modes. But I'm not so sure that
they have "outlived their usefulness". In fact, they may be
just the ticket in your situation. You are bandwidth-constrained here,
not by the monitor's video bandwidth but by the video card's video
bandwidth. You are currently operating your monitor at close to
your video card's maximum bandwidth (78.75 MHz vs. 80 MHz).
Yet you are operating at less than half of your monitor's maximum
vertical refresh rate (75 vs. 160). This is exactly what interlaced
modes are designed for!

It appears from the Xorg.0.log file that your
video driver and chipset support interlacing. I can't tell from
reading your monitor's manual whether it supports interlacing or not.
It doesn't say that it does, and it doesn't say that it doesn't.
The only way to find out is to try it.

Let's take a closer look at the modeline that your monitor is currently
operating under:

# 1024x768: 78.75 MHz, 60.0 kHz, 75.0 Hz
Modeline "1024x768" 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync

(You are not explicitly specifying this mode, it is being selected from
an internal table within the X server.) We will make three minor changes
to it. First, we will change the modeline name from "1024x768" to "custom".
Second, we will change the last number from 800 to 801 (interlaced modes
must have an odd vertical frame length). Third, we add the interlace flag.
Your full xorg.conf file will now look something like this:

----------

Section "Device"
Identifier "Configured Video Device"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
VendorName "Samsung"
ModelName "SyncMaster 550b"
HorizSync 30-70
VertRefresh 50-160
Option "MaxClock" "110"
# 1024x768: 78.75 MHz, 60.0 kHz, 150 Hz (interlaced).
Modeline "custom" 78.75 1024 1040 1136 1312 768 769 772 801 +hsync +vsync Interlace
EndSection

Section "Screen"
Identifier "Default Screen"
Device "Configured Video Device"
Monitor "Configured Monitor"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "custom" "800x600" "640x480"
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
EndSection

----------

Note that the word "custom" appears in two places: once in the Modeline
line in the "Monitor" section and the second time in the Modes statement
in the "Screen" section. This pretty much forces it to use your custom
mode. (But if it doesn't work you still have 800x600 and 640x480 to
fall back on via Ctrl+Alt+NumPlus and Ctlr+Alt+NumMinus.)

If it works, you will operate your monitor at 150 Hz vertical refresh!
Of course, it's an interlaced mode. It's not as good as 150 Hz vertical
refresh non-interlaced. But it's far superior to 75 Hz non-interlaced,
at least in theory. You might want to give it a try and see how you like
it.

Reducing flicker in a bandwidth-constrained environment is what interlaced
modes were created for in the first place. And that is the situation that
you are in.

I just recently changed monitors, and I'm in a similar situation.
I'm operating a custom interlaced mode right now as I compose this e-mail.
The monitor I'm using has a video bandwidth of only 70 MHz. The fastest
vertical refresh rate I can get at 1024x768 resolution using the standard
video modes is 60 Hz, and it runs at a dot clock of 65 MHz (close to the
maximum of 70 MHz).

# 1024x768: 65 MHz, 48.4 kHz, 60 Hz
Modeline "1024x768" 65 1024 1048 1184 1344 768 771 777 806 -hsync -vsync

But for me, 60 Hz produces noticeable flicker and eye strain. Although
I'm close to the maximum video bandwidth, I've still got plenty of room
in the vertical refresh department. My monitor has a maximum vertical
refresh rate of 100 Hz! There is a standard interlaced mode which runs
at 87 Hz, but just for grins I thought I'd try a custom mode. Here's
what I came up with:

# 1024x768: 54 MHz, 40.2 kHz, 99.6 Hz (interlaced)
Modeline "custom" 54 1024 1048 1184 1344 768 771 777 807 -hsync -vsync Interlace

This could probably be improved some more, but I just did a rough cut
using the one I started with as a template. I changed 806 to 807 to
get an odd number, then reduced the dot clock rate proportionately to
get the vertical refresh rate at 100 Hz. No more (perceived) flicker!
No tearing! No eye strain! It works great.


--
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  | 
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 ?