8. X11 SVGA DisplayTo make X11 work you MUST configure it. X11 runs on any supported display driver. XF86 is a well supported driver for Intel (386+) PC displays (and keyboard, and comms, and X11R6 base). See /var/X11R6/lib/doc/README XFree86 3.1.1 supports many 'brands' and SVGA chipsets. Most drivers are linked into /usr/X11/bin/XF86_SVGA, but others are available for various species of card, and different hardware modes (eg SVGA_Mono with 1 bit per pixel). The video card is driven 'directly' by XF86_SVGA or XF86_S3, and needs to know the correct set of timing values to drive the card and the display. If you are lucky, your user-group can help you. The answer is on the disks somewhere. |
This utility can be confusing. You run it once to create an initial /etc/XF86Config file, which you save with:
cp -p /etc/XF86Config /etc/X86Config.01
It will offer you a list of monitors, mine wasn't on the list. Chosing defaults for my 15", and telling xf86config the bandwidth range, sort of worked. I got better luck from manually editing the file, and grep'ing modeDB.txt.
xf86config will leave you with a working /etc/XF86Config, you just need to improve the list of timings. If you can only get 640x480 working, don't worry. I do most of my work at this resolution. You will need a larger virtual resolution, so that windows are larger than the screen, and you have to scroll the screen about a lot. The default virtual size is the maximum resolution.
However, it is nice to have 4 resolutions to switch between, to get different views. It makes the following worthwhile ... 24-bit is not covered here, or 1-bit or 4-bit. They use the same timings.
With slackware, you have the option of loading the driver relevent to your card (eg XF86_SVGA), and having it installed as the X driver. Look in /cdrom/slakware/FILE_LIST for a list of other drivers to browse. use mc to view inside tgz files without installing them. To install a slackware package, try:
tar -C / -zxf /slack/d9/package.tgz sh /install/install.sh
If you loaded all the XF86_S3* packages, they use different file names, but the last on in, gets installed as the X file, by setting the symbolic link in /usr/X11R6/bin.
NB: diskless stations often share /usr but not /var, so the /usr/X11R6/bin/X link will probably crossover to /var/X11R6/bin/X where it points back to /usr/X11R6/bin/XF86_SVGA.
The card emits a pixel to the screen every full cycle, ie 75 million times a second.
When the beam is 'off-screen', no pixel is output, and other wires may be sending signals such as V_SYNC, H_SYNC. But the card still counts in pixels (DOT CLOCK CYCLES) and lines. It may insist on multiples of 8, when counting.
Your card can be switched into a number of different frequencies. You select which work best for you. SEE: X -probeonly and SuperProbe
The monitor also has a maximum bandwith (90 or 140 MHz), above which pixels cannot be resolved by the amplifiers (edges fade, and lines go dim).
Having chosen the DOT-CLOCK (eg MCLK 80 MHz), you need a list of monitor timings that worked for somebody at that DOT-CLOCK. What matters is that they use the same monitor and DOT-CLOCK, not the same CARD.
You find several, and cautiously try them all out. You pick one and calculate it's timings, and adjust it with xvidmode. Repeat for several modes.
Your monitor has a quoted 'maximum' (and minimum) bandwidth, for both horizontal and vertical frequencies. If you exceed them it may catch fire, or not work properly.
These number are not really enough detail. As well as finding out how often you need a H_SYNC, you need to find out its acceptable width.
You can find a list of timings that made sense to somebody, in the MONITOR SECTION of modeDB.txt in /var/X11R6/lib/doc. But maybe thay had a fire-proof monitor.
You may also find the SVGA_LIB docs useful, they document a NON-X11 system.
This is the file where you put the numbers, along with names for them, and your mouse type.
I ran xf86config to scratch-generate this file, then editied in the timings. It sorted out all the syntax (and even got 640x480 working). You could also copy /var/X11R6/lib/XF86Config.eg
It can be located in any of 3 places, to confirm that your file is being found first, delete it and check that you can't startx because "No config file found!"
I have 3 button genius mouse, which emulates the Mouse-System Mouse.
Section "Pointer" Protocol "MouseSystems" Device "/dev/mouse" EndSection
For an easy life, don't read this, just find and adjust standard timings. This is for people who want to stretch their hardware to do more refreshes per second, or extra steps of resolutions.
Remember that the faster you make your card work, the more work it has to do - fetching data from memory, and the less time it has for CPU accessing memory, or optimisations (ie the card displays faster, but the machine draws slower).
BORDERS are the blank bits. You need them so that you can see the corners.
During the BORDER the beam may be ON screen, no pixels are drawn - and the border colour is used.
Much of the BORDER may be OFF screen, adjusting them will move the image to be central on the display. If a BORDER gets too thin, the drawing area may be too close to the SYNC pulse, or the beam position may be too far away from its expected value.
This is where pixels actually get drawn. The card will now be accessing its memory, reading bytes and sending pixels.
With 256 colours, each pixel-byte is looked up in a pallette, and the RGB intensities are send to the DAC's (digital to analogue), which sends the voltage/current to the monitor. The faster you run them, the hotter they get.
The monitor does not know it's in 256 colour mode or 24-bit mode. The card does.
During the H_SYNC pulse, the beam does it's fly-back, and the monitor sync's onto the repeated H_SYNC pulse.
During the V_SYNC the beam does it's fly-bak to the top.
In addition to fly-back, the monitor sync's onto the repeated timings of H_SYNC and V_SYNC. It compares them to pre-set values in its memory, and makes some attempt to scale the image width, height and offset.
The monitor may decide that the timings resemble those of a pre-set, and invoke parameters associated with that preset, ie on the front of the monitor are controls that regulate height and width. They get remembered.
The following diagram shows the left border on the left, which makes sense. However, XF86_SVGA counts from "0". Also note that these diagrams are NOT to scale, usually the h_sync pulse will be very thin compared to other values.
off visible off h_sync 3----+------------------+----+--------+ blank | BP | | | | BP +----0------------------+----+--------+ | | visible | | | | | screen | | | | | area | | | | | | | | | | | | | | | | | | | | | | | +----+------------------1----+--------+ blank | | | | | FP +----+------------------+----2--------+ v_sync | | | | | +----+------------------+----+--------3 BP FPIt also makes sense to count from the visible screen area, just remember that there IS a border before it, whose numbers appear to be last.
FP is the front porch, the distance from the end of the screen to the beginning of the h_sync and fly-back.
3----+ | BP | visible FP h_sync BP +----0------------------+----+--------+----+ | visible | | | | | screen | | | | | area | | | | | | | | | | | | | | | | | | | | | | | | +------------------1----+--------+----+ blank | | | | | +------------------+----2--------+----+ v_sync | | | | | +------------------+----+--------3----+ blank | | | | BP | +------------------+----+--------+----0
These two sets of numbers worked on a 15", the 65 MHz figure flickered at 52 Hz (ie frames per second), the 75-MHz looked more stable at 61 Hz. I used an 85 MHz clock to get 69 Hz, but that may be frying the DAC's.
You can comment out references to lines you don't want, and add variations, calling them "65-1024x768-a", "-b".
Modeline "75-1024x768" 75 1024 1160 1176 1368 768 820 822 903 Modeline "65-1024x768" 65 1024 1168 1192 1392 768 820 822 905Remember that '75' is an abbreviation of '75.23 MHz', so get the correct number for the calculations (xvidtune seems to know).
Display = 1024 = 8 x 128 (1024 pixels wide) BorderRight = 136 = 8 x 17 H_SYNC = 16 = 8 x 2 BorderLeft = 192 = 8 x 24 --------------------------- LINE TOTAL 1368 = 8 * 171 ---------------------------
The vertical timings are exactly the same format, but don't have to be 'multiples-of-eight'. Notice how much border time there is, especially off screen left.
If you experiment, changing border timings, or changing the SYNC pulse width, the cycles you add or trim, make it run slower or faster, ie effects the number of frames per second.
Display = 768 lines BorderLow = 52 V_SYNC = 2 BorderTop = 81 ----------------- Frame total 903 lines -----------------You may have noticed that only 64% (1024x768) pixels are used out of (1368x903).
Increasing 64% to 100%, would require an amazing monitor, and clever double banking memory accesses, or 64 bit memory lines. Accessing 24 bit data would be more.
This is in range 29-64 KHz, so it's ok for THIS monitor.
Section "Monitor" ... Bandwidth 85 # MHz HorizSync 29-64 # KHz VertRefresh 47-120 # Hz
These figures are 'for your protection' in /etc/XF86Config. They dis-allow mode lines that go outside these boundries. Many 17" monitors go to 135 MHz, if the card can generate it.
This is also in spec. Note that simply being in spec, doesn't make it work or look good! However, going out of spec is not a good idea.
70 Hz is your target for a good display. You can get 100 Hz at 640x480.
My monitor's specification came as a set of sample timing figures. You should be able to figure out the formulae to calculate them from the diagram.
Making sense of matching them is not so easy.
Interlaced mode is where every second screen scan, draws every second line. That makes the display more flickery, but allows higher resolutions at lower frequencies (on older monitors).
Err, yes. There is something about sync pulse polarity. This is some sort of special indicator between the card and the monitor. If you need it, you need it, but how you make sense of it is still a mystery to me, and I get by without it.
If you don't touch the keyboard or mouse, the screen will blank. This reduces phosphor burn. If you wait a while more, and if you have modern 'green' hardware, the card will switch the monitor off! (at least into a stand-by state). That further decreases phosphor burn, and save a lot of electricity (global resources). Touching the mose or the SHIFT key, brings it back.
To configure this, edit the following into /etc/XF86Config:
Section "Device" ... Option "power_saver" ... Section "Screen" ... SuspendTime 2 -and-also- /etc/rc.local - setterm -powersave on
These figures have worked for me so far. Just because they haven't yet started a fire, doesn't mean that they wont ...
If you do experiment with them, let me know your findings. If you do so with a range of monitors, publish and send the URL.
This shows the different syntax you can use.
USE THESE AT YOUR OWN RISK! --------------------------- Section "Monitor" Mode "1280x1024i_80_a" DotClock 80 # 88 Hz # 51.04 KHz # HTimings 1280 # h_resolution # 8 x 160 1440 # h_sync_start # 1480 # h_sync_end 1720 # h_end # before pix[0] VTimings 1024 # v_resolution 1080 # v_sync_start 1090 # v_sync_end 1210 # TLC Flags "Interlace" EndMode Modeline "65-1024x768" 65 1024 1168 1192 1392 768 820 822 905 Modeline "75-1024x768" 75 1024 1160 1176 1368 768 820 822 903 Modeline "85-1024x768 85 1024 1152 1168 1368 768 816 818 902 Modeline "50-800x600" 50 800 904 920 1064 600 637 643 706 Modeline "25-640x480" 25.175 640 664 760 800 480 491 493 525 Modeline "50-640x480" 50 640 696 760 850 480 515 520 580
CTRL-ALT-PLUS and CTRL-ALT-MINUS zoom through the list, which is pre-arranged in sorted order, found in Section "Screen", in the sub section for 8 bit depth displays.
If your monitor has a Hz and KHz display LCD, use it to check. xvidtune gives it's timings.
All you ever wanted to know ...
/var/X11R6/lib/doc/README - Hello XFree86 3.1.1 /var/X11R6/lib/doc/VideoModes.doc - HOW TO DO THIS PROPERLY /var/X11R6/lib/doc/README.cirrus - glitches + work arounds /var/X11R6/lib/doc/modeDB.txt - the answer is in here somewhere /var/X11R6/lib/doc/Monitors - the answer is in here somewhere /usr/X11R6/lib/X11 -> /var/X11/lib man XF86Config man xf86config man reconfig man xvidtune man xmodmap locate modmap /usr/X11R6/bin/xf86config - helps write XF86Config file /usr/X11R6/bin/xvidtune - view / adjust settings /usr/X11R6/bin/reconfig - convert old XF86Config file /usr/X11R6/bin/SuperProbe - told me CL-GD5429 /usr/X11R6/bin/viewres - when X running /usr/X11R6/bin/X -probeonly - what is groped OR set /var/X11R6/bin/X - xf86config may put it here /etc/XF86Config - best option -> next option /var/X11R6/lib/XF86Config - option /var/X11R6/lib/XF86Config.trix - option /var/X11R6/lib/XF86Config.eg - example template file /var/X11R6/lib/etc/xmodmap.std - xmodmap -e "keycode 22 = BackSpace" /var/X11R6/lib/Cards
Do not be confused by other facilities offered, such as creating your own XF86_my_card.c, and the makefiles used to compile and install the rest of the X11R6 base (lib/config).
skip these /usr/X11/lib/Server/XF86_SVGA.c - the driver link-kit /var/X11R6/lib/doc/VGADriver.doc /var/X11R6/lib/doc/INSTALL /var/X11R6/lib/config/.