8. X11 SVGA Display

To 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.

8.1 xf86config
8.2 Installing XF86_SVGA - x14/x312svga.tgz
8.4 Monitor: acceptable timings
8.5 /etc/XF86Config
8.6 Borders
8.7 Screen Area
8.8 H SYNC Pulse
8.9 V SYNC Pulse
8.10 Monitor Sync's on SYNCs
8.11 Timing Layout
8.12 Timing numbers
8.13 Horizontal: 1024 1160 1176 1368
8.14 Vertical: 768 820 822 903
8.15 Horiz: 75.0 MHz / 1368 clocks per line = 54.8 KHz
8.16 Vert: 54.8 KHz per line / 903 lines = 60.7 Hz
8.17 H_SYNC_PULSE = 16/75.0 Mhz = 0.21 usec
8.18 Interlaced mode
8.19 Special Options - anything else ?
8.20 Power Saving Options
8.21 Example Syntax
8.22 Switching Modes
8.23 quick route
8.24 README's and places to look



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.


Installing XF86_SVGA - x14/x312svga.tgz

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.


Monitor: acceptable timings

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!"

Setting mouse type

I have 3 button genius mouse, which emulates the Mouse-System Mouse.

Section "Pointer"
	Protocol    "MouseSystems"
	Device      "/dev/mouse"

FRAME: Borders Screen and SYNC Pulses

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.


Screen Area

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.


H SYNC Pulse

During the H_SYNC pulse, the beam does it's fly-back, and the monitor sync's onto the repeated H_SYNC pulse.


V SYNC Pulse

During the V_SYNC the beam does it's fly-bak to the top.


Monitor Sync's on SYNCs

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.


Timing Layout

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    
  blank	 | BP |                  |    |        | BP
	 |    | visible          |    |        |
	 |    | screen           |    |        |
	 |    | area             |    |        |
	 |    |                  |    |        |
	 |    |                  |    |        |
	 |    |                  |    |        |
	 |    |                  |    |        |
  blank	 |    |                  |    |        | FP
  v_sync |    |                  |    |        |
	   BP                      FP
It 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.

	 | BP | visible            FP   h_sync   BP
	      | visible          |    |        |    |
	      | screen           |    |        |    |
	      | area             |    |        |    |
	      |                  |    |        |    |
	      |                  |    |        |    |
	      |                  |    |        |    |
	      |                  |    |        |    |
  blank	      |                  |    |        |    |
  v_sync      |                  |    |        |    |
  blank	      |                  |    |        | BP |


Timing numbers

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  905
Remember that '75' is an abbreviation of '75.23 MHz', so get the correct number for the calculations (xvidtune seems to know).


Horizontal: 1024 1160 1176 1368

	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.


Vertical: 768 820 822 903

	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.


Horiz: 75.0 MHz / 1368 clocks per line = 54.8 KHz

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.


Vert: 54.8 KHz per line / 903 lines = 60.7 Hz

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.


H_SYNC_PULSE = 16/75.0 Mhz = 0.21 usec

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

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).


Special Options - anything else ?

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.


Power Saving Options

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


Example Syntax

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.


Section "Monitor"
Mode	"1280x1024i_80_a"
	DotClock	80 		# 88 Hz	# 51.04 KHz #
		1280	# h_resolution		# 8 x 160	
		1440 	# h_sync_start		# 
		1480 	# h_sync_end
		1720 	# h_end # before pix[0]
		1024 	# v_resolution
		1080 	# v_sync_start
		1090 	# v_sync_end 
		1210 	# TLC
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 


Switching Modes

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.


quick route


README's and places to look

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"

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