FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 01-09-2010, 06:53 PM
Stephen Powell
 
Default Undefined video mode number: 314

On 2010-01-09 at 12:52:03 -0500, Stanisław T. Findeisen wrote:
> Hi!
>
> I am trying to install Debian 5.0.3 on AMD 64 platform. My motherboard
> is ASUS K8U-X (Socket 754). I downloaded debian-503-amd64-netinst.iso
> and chose "graphical expert install". Then I got this:
>
> Undefined video mode number: 314
>
> and was offered a selection of a number of text modes.
>
> I continued installation in text mode, but now I am unable to run X. I
> guess graphical login should appear, but instead the monitor turns off.
> I can however switch to text console and use Debian in text mode.
>
> Any ideas? I need graphical mode!

Exactly how do you "switch to text console"? Do you use Ctrl+Alt+F1?
If so, does the procedure work if you simply use Alt+F1? Or does it not
work unless you include Ctrl? What I'm trying to determine here is
if the X server really did start. If it did, but you have a black screen,
then Ctrl+Alt+F1 would work to switch you to a text console, but Alt+F1
would not work. You haven't told us anything about your video chipset
or monitor either. A good place to start would be to examine the file
/var/log/Xorg.0.log to look for error messages.

dpkg-reconfigure xserver-xorg

might help too. From what little information I have to go on, it sounds
like the X server has chosen a video mode that your monitor cannot handle.
Please provide specifics on your video card, video chipset, and monitor.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-09-2010, 08:00 PM
"Boyd Stephen Smith Jr."
 
Default Undefined video mode number: 314

In <4B48ECA8.8040407@gmail.com>, Stanisław T. Findeisen wrote:
>(II) s3(0): Not using default mode "1024x768" (insufficient memory for mode)
>
>What does this mean?? Is my graphics card memory already too little to
>run X?? How much video memory is needed to run X? I am sure both the
>monitors support 1024x768.

For 1024x768 and 32-bit color depth you'll need 1024x768x32 bits = 1024x768x4
bytes = 768x4 KiB = 3x256x4 KiB = 3x1024 KiB = 3 MiB. So, you'll probably
need 3MiB of video memory. You could run in 8-bit mode though; them you'd
only need 768 KiB.

Besides not having enough video memory, it's possible that X is detecting the
amount of video memory you have incorrectly.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 01-11-2010, 12:48 AM
Stephen Powell
 
Default Undefined video mode number: 314

On 2010-01-09 at 15:52:56 -0500, Stanisław T. Findeisen wrote:
> Below I attach complete /var/log/Xorg.0.log :

The X server detected 2048K (2M) of video RAM on your card.
The X server also defaulted to a color depth of 24. This means
that 24 bits, or three bytes, of video RAM are needed for each
pixel. This is known as "true color" mode. At the default desktop
size of 1024x768, you would need 1024*768*3, or 2,359,296 bytes
of video RAM to specify the color information for each pixel.
Dividing by 1024 to convert to "K", that yields 2304K of video
RAM, which is more video RAM than is installed.

I would suggest
that you drop the color depth down to 16. This is 16-bit color
or "high color" mode. It's not quite as good as 24-bit color,
but pictures still look pretty good.

On my web site at

http://www.wowway.com/~zlinuxman/tp600.htm

you will find an example X configuration file which specifies
a color depth of 16. Don't copy it verbatim, because it is
designed for a different video chipset. But it does provide
a useful template to get you started.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-12-2010, 02:43 PM
Stephen Powell
 
Default Undefined video mode number: 314

On 2010-01-11 at 15:52:56 -0500, Stanisław T. Findeisen wrote:
> I tried "VertRefresh 85" because I know this monitor can handle 1024x768
> @ 85 Hz (well, at least it used to several years ago). Unfortunately the
> error I am getting now is: "vrefresh out of range" and I am only able to
> run X at:
>
> 720x400x16 @ 85Hz, or
> 800x600x16 @ 60Hz

Well, we're making progress. Your monitor apparently does not support
DDC2/EDID; so the X server does not know what your monitor's horizontal
and vertical sync frequency ranges are. You have to tell it. The "safe"
assumptions that the X server is making are well below your monitor's
capabilities.

You probably don't need to compose your own modeline though. Let's see.
You told me that your monitor is a Samsung SyncMaster 550b. According to
the owner's manual, which I found on the Internet, the horizontal sync
frequency range is 30 kHz to 70 kHz, and the vertical sync frequency range
is 50 Hz to 160 Hz. The video bandwidth (maximum pixel clock) is 110 MHz.
That's less than the maximum pixel clock rate supported by the video card;
so you should be OK there, as we can see from

> (--) s3(0): Max pixel clock at this depth is 80 Mhz

So your monitor section (you should have only one monitor section)
should look something like this:

Section "Monitor"
Identifier "Configured Monitor"
VendorName "Samsung"
ModelName "SyncMaster 550b"
HorizSync 30-70
VertRefresh 50-160
Option "TargetRefresh" "75"
EndSection

The "TargetRefresh" option is optional. If used, it will try to use only
video modes of 75 Hz vertical sync or higher. Give that a whirl and see
what happens. Make sure that you are specifying the color depth as 16
(DefaultDepth 16 in the "Screen" section).


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2010, 01:13 PM
Stan Hoeppner
 
Default Undefined video mode number: 314

"Stanisław T. Findeisen" put forth on 1/13/2010 6:18 AM:

> With this I am able to run 1024x768x16 @ 75 Hz! However, I wanted 85 Hz.

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.

> (**) 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

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2010, 03:57 PM
Stephen Powell
 
Default Undefined video mode number: 314

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2010, 05:41 PM
Stephen Powell
 
Default Undefined video mode number: 314

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-15-2010, 01:54 PM
Stephen Powell
 
Default Undefined video mode number: 314

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-16-2010, 03:31 PM
Stephen Powell
 
Default Undefined video mode number: 314

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2010, 03:15 AM
Stephen Powell
 
Default Undefined video mode number: 314

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org