A Voodoo 3 driver stops assuming the firmware already ran its video BIOS

There are two ways for a driver to depend on a video BIOS. One is to let something else run it as code, which is what x86 firmware does at boot and what tdfxfb has relied on since it was written ^[10]. The other is to read it as data and do the register writes yourself. Daniel Palmer's patch does the second: it pulls configuration values out of the card's own ROM and brings the VGA core up from inside Linux ^[5].

That swap moves the failure mode rather than removing it. Instead of needing a platform whose firmware will execute a 1990s option ROM, you need a ROM whose layout the driver has been taught. The bill arrived immediately. VSA-100-based Voodoo 4 and 5 cards were in the original scope and came out of the series because their BIOS layouts are different ^[17]. Same vendor, same era, same driver, and the parsing work does not transfer.

This is where the two write-ups part company. Phoronix reports that TDFXFB can now initialize Voodoo 3, 4 and 5 cards without a PC BIOS ^[7]; Tom's Hardware reports that the 4 and 5 support was pulled from the current patch series ^[17]. Of the three families named, the merged manual initialization path covers one ^[16]. Anyone with a VSA-100 card and a non-x86 host should assume the smaller number.

Judged as a graphics feature, the result is thin. On an x86-64 box, loading the driver gets you a framebuffer device, usually /dev/fb0, good enough to host the virtual console ^[11], on an interface that DRM/KMS superseded long ago and that carries no Mesa, no modern OpenGL and no acceleration ^[12]. The value is not in the card. It is in the class of machine where nothing will ever POST that card: Palmer's own trigger was a Voodoo 3 in an Amiga 4000 behind a PCI bridge, detected by Linux and outputting nothing ^[4]. His patch description generalises it to non-x86 systems, setups where another card is primary, and firmware too new to run the old video BIOS ^[3]. Those are three different ways of saying the same thing, which is that x86 POST behaviour was an unstated part of the driver's contract for two decades.

The framebuffer work is also the boring half. Palmer has a separate path that exposes the Voodoo's register space to userspace through a /dev/tdfx3d misc device, with a small library called smoltdfx and an OpenGL 1.x implementation called smolminigl on top, which he says renders on real hardware without X, Mesa or Glide ^[13]. Phoronix notes the merged patches were tested against those 3D patches, which are not yet merged ^[9]. Palmer says Claude helped build a QEMU model of the card in the first place, to debug why the Amiga would not bring it up ^[8].

The other half of the same pull request is the tell about where this kind of work lives now: ATAFB gained 8-bit chunky, RGB565 and ARGB888 depths plus support for the SuperVidel SuperBlitter, a co-processor upgrade sold for the Atari Falcon ^[14][15]. fbdev is legacy, and it is also the only place hardware with no DRM driver can be made to display anything.