Graphics drivers for Plan 9 are divided into two components. The kernel component is responsible for enabling the hardware, handling the cursor, and providing accelerated fill and scroll functions, among other things. The userland component, named aux/vga, is responsible for modesetting and implementing an interface to the card. Thankfully, this is all nicely detailed in /sys/src/cmd/aux/vga/notes.txt.
The three files {radeon.c, radeon.h, radeon_pciids.h} are part of the userspace component of the driver, and consequently go into /sys/src/cmd/aux/vga. To install them, copy the above files into that folder, and then perform the following steps:
- Update the mkfile by adding the text " radeon.$O\" as part of the $OFILES variable, in the obvious way.
- Add the lines "extern Ctlr radeon;" and "extern Ctlr radeonhwgc;" to vga.h. This allows the vgadb to determine which controller to activate.
- Add the lines "&radeon," and "&radeonhwgc," to data.c in the obvious location.
- Build the program by issuing the "mk" command, and observe that 8.out is successfully created.
If you grep for "nvidia", you'll notice that this string is contained within certain files without extensions that provide build targets for mk. Specifically, these files are: {pc, pccd, pccpuf, pcdisk, pcf, pcfl, pcflop}. To each of these files, add the line " vgaradeon +cur" immediately after the " vganvidia +cur" line. Then issue "mk 'CONF=pcdisk'", and observe that the "pcdisk" file is built successfully.
[Do note, however, that the kernel Radeon driver depends on the {radeon.h, radeon_pciids.h} files in aux/vga, and that if you are building from a location other than /sys/src, you may have to change radeon.c to address the headers relatively, for example by "#include ../../cmd/aux/vga/radeon.h".]
Finally, we need to update the /lib/vgadb file with Radeon PCI device IDs, so that aux/vga can map them with the radeon and radeonhwgc controllers. Since I don't have write permissions on /lib/vgadb, I instead rebound an updated file over it in my namespace. You can do this by running "cat radeon_vgadb /lib/vgadb > $home/vgadb_radeon", and then overlay this new file on top of the original by running "bind $home/vgadb_radeon /lib/vgadb". If you have a Radeon card covered by the pciids in the driver, your new aux/vga version should be able to identify it.
This concludes the explanation of how to install the Radeon driver for Plan 9.
Unfortunately, for my special case, it isn't exactly as simple. The function that the kernel and aux/vga use to find a suitable Radeon card is called pcimatch(), which exists in both /sys/src/9/pc/pci.c (with the header "Needs a massive rewrite.") and /sys/src/cmd/aux/vga/pci.c (with no such header). This function takes a callback-like object (very useful in a few seconds!), a vendor ID, and a device ID, and attempts to locate a match in the PCI list. Both kernel and userspace radeon drivers use this function while specifying a device ID of 0, which means "I don't care what the device ID is; just find me something that has ATI as the vendor."
I have an ATI motherboard. If I issue the "pci" command, it becomes pretty evident that ATI is listed as the vendor for 12/17 of the devices on my system. So, the driver's default action is to complain that my Fast EtherLink PCI TX is not a known graphics card, and then drop out. The suboptimal solution is to use the first argument of pcimatch() to look for the next device with the same vendor ID, and so on. That's what I am doing, because it doesn't involve changing pcimatch().
A better solution would be to have pcimatch() take an int list of valid device IDs for that vendor. I should figure out who owns that file (how?).