On Mon, Dec 16, 2002 at 06:45:00PM +0000, joachim.henke@stud.tu-ilmenau.de wrote:

On http://www.medex.hu/~danthe/tdfx/ I found a newer version of the tdfxfb
driver. It was a patch against linux 2.4.4 . I don't know why it never went
into the kernel. Maybe Linus was too busy at that time?

The current kernel still contains version 0.1.3 which is rather old. Much
work has been done until version 0.2.2, mainly support for:

* non-8 dot wide fonts
* multihead
* full 8/16/24/32 bit color (fixes the ugly bootup penguin)
* MIPS
* module options

I think it's worth to give it a chance and to continue development on the
base of that code. So I "ported" it to kernel 2.4.2x. Get this new patch
here:

http://tu-ilmenau.de/~johe-ii/3dfx-0.2.2-2.4.21-pre1.diff.gz

I just merged the improvements that happened to v0.1.3 while it was in the
kernel and did some source formating.

Be encouraged to test it, do further improvements and please take it into
the kernel!

I try this out on 2.4.20 with other patching.
My machine is an Asus super 7 (K6 500) with PCI & AGP voodoo banshees.
BIOS requires boot VGA to be PCI.

Both heads are init by driver, BIOS head is head 0. Head 1 is
misdetected to be only 4096KB video memory, should be 16384KB as is head
0. After remapping a virtual console to fb/1, I have no video signal on
either head now until I fbset each to depth 16.

Tested system with mplayer output to tdfxfb driver. Video only on fb/0,
but with mplayer on console on fb/1 both heads are responsive.

Unfortunately I tried mplayer with DirectFB, it crashes unable to init,
and (it's enabled with xfs patch) I get into gdb. And my keventd kernel
thread is zombie. sysrq kessages appear on (current) fb console, but
consoles otherwise unresponsive.

I try mplayer with tdfxfb again. No complaints but also no image on fb/0