S3 Savage/MX and Savage/IX

XFree86 3.3.6

XFree86 4.0.2 driver available! Click here.

Although the XFree86 web page implies that the Savage/MX and Savage/IX chips are supported in XFree86 3.3.6, that is not, in fact, true. The XF86_SVGA server includes code for detecting the /MX and /IX, but no code for drawing to them. I now have a patched version of the server which includes this support.

This server is basically the original XFree86 3.3.6 with additional support for these chip variants:

• Savage/MX-MV (PCI id 8C10)
• Savage/MX (PCI id 8C11)
• Savage/IX-MV (PCI id 8C12)
• Savage/IX (PCI id 8C13)

Of course, it also supports the other members of the Savage family (3D, 4, 2000, PM133, KM133, Twister, TwisterK).

Most of this patch is now part of XFree86, as of 3.3.6 fix08. The server binary here has a few updates over fix08, which should be incorporated into XFree86 by XFree86 3.3.7, assuming there is a version 3.3.7. Using the S3 numbering scheme, this server will eventually be known as 1.0-15.

Late breaking news:

The Linux server binary was updated on February 14, 2001, to add a universal and reliable workaround for the infamous scrolling hang. The workaround has been in place for a week or in the 4.0.2 driver, and thus far EVERYONE who has tried it reports that the hangs are gone. A big "thank you" to Frank Mehnert and Jork Loeser of Dresden University, for their detective work in creating this very clever workaround.

In 4.0.2, the workaround is enabled using an XF86Config Option. Because the "Option" scheme in 3.3.6 is not as flexible as in 4.0.2, you will have to export an environment symbol. If you use sh/bash/ksh:

• export SAV_SHADOW_STATUS=1

• setenv SAV_SHADOW_STATUS 1

The Linux server binary was updated on October 24 to work around what appears to be a video BIOS bug in the more recent Toshiba Satellite Pro 43X0 laptops. The symptom is that the server hangs on startup until you do something like Ctrl-Alt-F1 to force a VT switch interrupt. The workaround seems to solve the problem.

The server binary was updated on September 29 to fix a problem with 1400x1050 support. This mode is now known to work on the IBM T21. Here is a 1400x1050 mode line that was reported to work by the engineers at LinuxCare:
            ModeLine "1400x1050" 122.00 1400 1464 1784 1912 1050 1052 1064 1090 -HSync -VSync

Known Issues

Text Scrolling Hang: This problem should now be eliminated through the use of the shadow status feature described above.

VT-Switching: There is a known issue when bringing down the server on non-Linux and non-x86 systems. I have some kind of a register timing or write-order problem that I have been unable to resolve. I was able to work around it by calling the video BIOS to switch to mode 3 before exiting the server, but the video BIOS code only works on Linux/x86. If you encounter screen hangs when killing the server, let me know, and let me know a little about your environment. Since the /MX and /IX were designed for laptops, I don't expect to get a lot of exposure in non-x86 environments.

Snow on FreeBSD at 32bpp: When the server is build for FreeBSD, the 32-bit modes get "sparklies" on the screen during rapid activity. The snow is not intolerable, but it is annoying. I am working on this issue.

Environments:

This driver has been tested rather extensively on the Toshiba Tecra 8100 (Savage/MX) and the Toshiba Satellite 4200, 4300, and 2775DVD (Savage/IX). It is also getting a fair amount of testing on the IBM T20 and T21 (Savage/IX), especially with FreeBSD. It also works on the Samsung GT8000, and the ASUS L8400s. If you're using another platform, drop me a note at timr@probo.com to let me know which one.

There is a known conflict when using this server on Linux with a graphical console at 32bpp (vga=792 in /etc/lilo.conf). However, it seems to work fine with a graphical console at 16bpp (vga=791).

The server does not work on Linux installations launched via loadlin from MS-DOS. The issue is complicated. As DOS boots, drivers and TSRs hook themselves into the video BIOS interrupt (INT10). So by the time DOS is running, INT10 points somewhere in DOS real memory, instead of into the VGA BIOS. The INT10 code in the Savage server only maps the VGA BIOS into memory. The first time I do an INT10, I'm jumping into code which no longer exists. They tell me it is possible to make this work by killing all TSRs before running loadlin. A sufficiently motivated person could also use DEBUG in DOS to trace through an INT10 call, watch for the first time it actually jumps to a C000:xxxx address, and write a small program to shove that address into the INT10 vector at 0000:0040 before running loadlin.

Since there have only been about three reports of this, I will probably not devote much attention to it.

You have a choice when using RedHat 7.0 or Mandrake 7.2. These distributions ship with BOTH XFree86 4.0.1 and XFree86 3.3.6, and you can actually use either one with your Savage. To use the 3.3.6 code, configure X to use the generic XF86_SVGA server. RH7.0 switches back to XFree86 3.3.6 in this case. Then, replace the XF86_SVGA binary with the version from this web site. Your mileage may vary, but I've had more GOOD reports than BAD reports from this. If you'd rather use the 4.0 driver, click here. You will have to upgrade to XFree86 4.0.2; 4.0.1 isn't enough.

Links

IMPORTANT NOTE!!! The binaries below are not all current! The Linux binary is the most up-to-date. The FreeBSD version is one version behind; it lacks the shadow status fix. The source matches the Linux binary.

Thanks to Steve Ihde for building the Debian distribution. Thanks to Greg Putrich and Rob Harris for building the updated FreeBSD binary.

Legal Stuff

Take appropriate precautions. Although extensive testing suggests this software is quite stable, this is an open source product, and there is no warranty. The prudent computer user always makes regular backups. I learned that this summer when my laptop's hard disk developed a flaw in the Windows System directory (a mechanical Freudian slip, perhaps?). Neither I nor S3 Graphics can be held responsible for any damage which might be caused by this software.

Last modified Wednesday, March 21, 2001.