X4 incorrectly probes savage4 VideoRam
Hi,
My /etc/apt/sources.list has been a regular subscriber to X strike
force for a long time now (thanks a lot Branden!) and I've been having
this problem ever since the XFree 4.X series started.
I have a:
...
spitfire:~# lspci -v -s 01:00.0
01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04) (prog-if
00 [VGA])
Subsystem: Diamond Multimedia Systems SpeedStar A90
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 11
Memory at d9000000 (32-bit, non-prefetchable)
Memory at d0000000 (32-bit, prefetchable)
Capabilities: [dc] Power Management version 1
Capabilities: [80] AGP version 2.0
...
With 16MB of VideoRam (which I know because I bought it this way (I
should have bought a Matrox or a 3dfx, oh well...) and because it
flashes 16MB on the initial boot up screen). But XFree86 insists on:
...
(--) SAVAGE(0): probed videoram: 32768k
...
even though I tell it:
...
Section "Device"
Identifier "DiamondSavage"
Driver "savage"
VideoRam 16384
BusID "PCI:1:0:0"
EndSection
...
There is no other message in X output recognizing my explicitly stated
VideoRam. Looks like XFree86 (or the savage driver) is completely
ignoring the VideoRam keyword. Otherwise it seems to be recognizing
and probing correct values for everything else including the chipset
(Savage4).
This is causing me different problems depending on which motherboard I
plug it to:
In my house machine (an AMD 500Mhz in an ASUS motherboard,
where most components and bridges come from Acer Laboratories Inc.), 2
out of every 4 pixel columns are completely white at 32bpp and 2 out of
every 8 pixel columns are white at 16bpp. Various artifacts mess
up the screen during the whole time. An accelerated X cursor will draw
correctly (without white columns on top of the cursor gliph). but will
be closely followed by a pair of rectangular boxes the size of the
cursor glyph that invert every color on screen (including the white
columns).
In my work machine (a 650 MHz Pentium III where most components and
bridges come from VIA Technologies) it seems to work mostly correctly,
but if I change modes (or switch between console and X) too much it
locks up the machine hard (no network, no keyboard, only the reset
button works :-)
I have tried everything I know of, including changing the agp graphics
aperture size in bios setup. I suspected it wouldn't help and it
didn't.
What should I do now? File a bug report against XFree86 package? Dive
into source code and see if I can find why VideoRam isn't being
respected?
I can send my full XF86Config-4 and X output if anyone is interested.
With 3.3.6, XF86_SVGA segfaults in my work machine after wrongly
probing 32MB, but if I specify the VideoRam it respects the setting,
but still segfaults. In my home machine it actually kind of works (if
I specify the VideoRam), but it cannot correctly synch 1024x768 on my
old SyncMaster 3 monitor, the screen spins wildly.
Since we are talking about X and S3 boards, does anyone know why S3
Vision drivers haven't been ported from XFree86 3.3.6? I have a
perfectly good Diamond Stealh with a memory extension daughterboard
and both XF86_SVGA and _S3 know how to drive it (mostly) correctly.
And why the savage series are not supported in DRI project? utah-glx
at least has an experimental driver...
Regards, Leo
Reply to: