Re: 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" DefaultDepth16 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 de
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314 --- OT question
On 2010-01-13 at 14:11:50 -0500, Stan Hoeppner wrote: > Or he can do what the rest of the world is doing and buy a flat panel LCD > monitor, where no such thing as a vertical refresh rate exists, nor flicker, > nor > eye fatigue. Thus, he could keep his S3 card, running at the highest res and > color depth it will do at 60 Hz, which is the default input signal most DB15 > VGA > port equipped LCD monitors expect to see. > > I've used nothing but DVI and HDMI with LCDs, so I'm unsure, but, it may be > possible for him to run his S3 at a lower vertical Hz, like 56 or something, > to > wring the maximum res and color depth out of his S3 card. I'm guessing from > the > situation that a new LCD probably isn't in the cards. Yes, that would be an option too. And you're right: the vertical refresh rate becomes a moot point on LCD displays. But given his existing hardware, his system is currently optimized about as much as it can be. I've been using a CRT monitor for years at 75 Hz vertical refresh and never had a problem with eye fatigue. If it were me, I'd be perfectly content. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314 --- OT question
Stephen Powell put forth on 1/13/2010 1:00 PM: > On 2010-01-13 at 13:41:16 -0500, Paul E Condon wrote: >> A different way of putting my question is: Is it really your eyes that >> cannot detect, or is it that you mind that cannot perceive the >> flicker? > > That's a good question. I wish I had a good answer to go with it. > Obviously, higher is better. But if he wants a higher vertical > refresh rate, he's either going to have to use a more capable video > card or else live with lower resolution. That's the bottom line. Or he can do what the rest of the world is doing and buy a flat panel LCD monitor, where no such thing as a vertical refresh rate exists, nor flicker, nor eye fatigue. Thus, he could keep his S3 card, running at the highest res and color depth it will do at 60 Hz, which is the default input signal most DB15 VGA port equipped LCD monitors expect to see. I've used nothing but DVI and HDMI with LCDs, so I'm unsure, but, it may be possible for him to run his S3 at a lower vertical Hz, like 56 or something, to wring the maximum res and color depth out of his S3 card. I'm guessing from the situation that a new LCD probably isn't in the cards. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314 --- OT question
On 2010-01-13 at 13:41:16 -0500, Paul E Condon wrote: > A different way of putting my question is: Is it really your eyes that > cannot detect, or is it that you mind that cannot perceive the > flicker? That's a good question. I wish I had a good answer to go with it. Obviously, higher is better. But if he wants a higher vertical refresh rate, he's either going to have to use a more capable video card or else live with lower resolution. That's the bottom line. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314 --- OT question
On 20100113_115748, 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 --- snip all the interesting stuff about monitors and video cards --- > 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. > Flicker and perception of flicker interest me as a scientific problem: Is the maximum perceived flicker frequency a property of the optic nerves in the retina, or is it the result of some frequency filtering or data averaging in the nerves of the visual cortex? If it is a feature/function of the visual cortex then one might expect that there could be fatigue of the visual system from the activity of removal even though there is no conscious knowledge that flicker was there in the raw input signal. OTOH, if the raw signal simply has a upper-half-power frequency in the range of a few tens of hertz, then there should be no excess mental activity and no fatigue. Conventional wisdom is that if you can't see it, it can't harm you --- but I wonder. A different way of putting my question is: Is it really your eyes that cannot detect, or is it that you mind that cannot perceive the flicker? Any thoughts on this? Seems like there could be an experimental study of this issue. Has it been done? -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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" . . . DacSpeed110 . . . 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
Re: Undefined video mode number: 314
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 signature.asc Description: OpenPGP digital signature
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314
Stephen Powell wrote: > 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. What are those sync frequency ranges? > 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 Less?? > 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). With this I am able to run 1024x768x16 @ 75 Hz! However, I wanted 85 Hz. (**) 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. Where do those modes come from, if there are none in the config file and my monitor does not support EDID? 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? 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"... I also tried TargetRefresh=85 but with no success. I would say maximum pixel clock rate supported by the video card is 80 MHz and *that* is the limit?... STF http://eisenbits.homelinux.net/~stf/ OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A signature.asc Description: OpenPGP digital signature
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314
Stephen Powell wrote: > 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. Yeah, thanks, I used to edit those X config files years ago on RedHat, so this isn't *that* new to me. I have something like this: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "pl" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" EndSection Section "Device" Identifier "Configured Video Device" Option "UseFBDev" "true" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Monitor" Identifier "SSM 550b" VendorName "Samsung" ModelName "SyncMaster 550b" VertRefresh 85 EndSection Section "Screen" Identifier "Default Screen" Monitor "SSM 550b" DefaultDepth16 Subsection "Display" Depth 16 Modes "1024x768" EndSubSection EndSection 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 (nothing better). (**) s3(0): Chipset: "Trio32/64" (--) s3(0): Framebuffer @ 0xfb00 (--) s3(0): videoRam = 2048 Kb (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (--) s3(0): MCLK 55.036 Mhz (--) s3(0): RefClock: 16000 (--) s3(0): Max pixel clock at this depth is 80 Mhz (II) s3(0): SSM 550b: Using default hsync range of 31.50-37.90 kHz (II) s3(0): SSM 550b: Using vrefresh value of 85.00 Hz (II) s3(0): Clock range: 15.60 to 80.00 MHz (II) s3(0): Not using default mode "640x480" (vrefresh out of range) (II) s3(0): Not using default mode "320x240" (vrefresh out of range) (II) s3(0): Not using default mode "640x480" (vrefresh out of range) (II) s3(0): Not using default mode "320x240" (vrefresh out of range) (II) s3(0): Not using default mode "640x480" (vrefresh out of range) (II) s3(0): Not using default mode "320x240" (vrefresh out of range) (II) s3(0): Not using default mode "640x480" (hsync out of range) (II) s3(0): Not using default mode "320x240" (hsync out of range) (II) s3(0): Not using default mode "800x600" (vrefresh out of range) (II) s3(0): Not using default mode "400x300" (vrefresh out of range) (II) s3(0): Not using default mode "800x600" (vrefresh out of range) (II) s3(0): Not using default mode "400x300" (vrefresh out of range) (II) s3(0): Not using default mode "800x600" (hsync out of range) (II) s3(0): Not using default mode "400x300" (hsync out of range) (II) s3(0): Not using default mode "800x600" (hsync out of range) (II) s3(0): Not using default mode "400x300" (hsync out of range) (II) s3(0): Not using default mode "800x600" (hsync out of range) (II) s3(0): Not using default mode "400x300" (hsync out of range) (II) s3(0): Not using default mode "1024x768" (vrefresh out of range) (II) s3(0): Not using default mode "512x384" (vrefresh out of range) (II) s3(0): Not using default mode "1024x768" (hsync out of range) (II) s3(0): Not using default mode "512x384" (hsync out of range) (II) s3(0): Not using default mode "1024x768" (hsync out of range) (II) s3(0): Not using default mode "512x384" (hsync out of range) (II) s3(0): Not using default mode "1024x768" (hsync out of range) (II) s3(0): Not using default mode "512x384" (hsync out of range) (II) s3(0): Not using default mode "1024x768" (hsync out of range) (II) s3(0): Not using default mode "512x384" (hsync out of range) (II) s3(0): Not using default mode "1152x864" (hsync out of range) (II) s3
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314
Boyd Stephen Smith Jr. wrote: > In <4b48eca8.8040...@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. Hm, I thought I have more memory than that, but apparently this is false. :-( How do I change color depth? I tried: dpkg-reconfigure xserver-xorg but it only allows for keyboard layout selection and little more. > Besides not having enough video memory, it's possible that X is detecting the > amount of video memory you have incorrectly. STF http://eisenbits.homelinux.net/~stf/ OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Undefined video mode number: 314
In <4b48eca8.8040...@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. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Undefined video mode number: 314
Stephen Powell wrote: > 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? Yes. > If so, does the procedure work if you simply use Alt+F1? No. > 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. graphics card: S3 Trio64 (plugged via PCI) monitor: Samsung SyncMaster 550b (this is a CRT monitor; I also tried with a newer LCD (after installation) but it didn't help) mb chipset: ULI M1689 (in Xorg.0.log: "(--) Chipset Trio32/64 found") mb: http://www.asus.com/product.aspx?P_ID=9A2K9jFcnqjqzAZr In /var/log/Xorg.0.log I can see lines like this one: (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. Below I attach complete /var/log/Xorg.0.log : X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-10.lenny2) Current Operating System: Linux k8ux 2.6.26-2-amd64 #1 SMP Thu Nov 5 02:23:12 UTC 2009 x86_64 Build Date: 11 June 2009 09:45:25AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jan 9 21:14:27 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Configured Monitor" (==) No device specified for screen "Default Screen". Using the first device section listed. (**) | |-->Device "Configured Video Device" (==) |-->Input Device "Configured Mouse" (==) |-->Input Device "Generic Keyboard" (==) The core pointer device wasn't specified explicitly in the layout. Using the first mouse device. (==) The core keyboard device wasn't specified explicitly in the layout. Using the first keyboard device. (==) Automatically adding devices (==) Automatically enabling devices (==) No FontPath specified. Using compiled-in default. (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x7c31c0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Undefined video mode number: 314
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! STF http://eisenbits.homelinux.net/~stf/ OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
