I've been hired by LinuxFund as a part-time coder on various projects. It's part of a stipend-type program they're trying out for students. So far I've begun work on porting the ADMTek wireless driver from NetBSD to FreeBSD then linux (needs a ton of work still) based on Sam Leffler's wireless framework for linux/FreeBSD, committed my Rage 128 pageflipping code to DRI CVS, and I'm currently spending my time on getting the SiS DRI working in DRI CVS.
After hating CVS for a long time, I've started seriously playing with Perforce to manage code I'm working on. Trying to produce diffs and merge between branches/dates has always been terrible for me with CVS in the DRI project. I'd started using perforce in a basic manner for FreeBSD with the plex86 stuff, since we have a perforce repository for WIPs in the project. I started doing the SiS work in perforce, and the ease of committing and reviewing what I did in small but multifile changes has been great. So I decided to use it to solve my problem of merging the DRM between DRI CVS and FreeBSD. The problem is that the DRM has to be changed somewhat to live in the kernel tree. Before, I would copy the files manually from DRI CVS into the kernel tree, apply a script to edit the #includes, and then manually re-add the $FreeBSD$ tags required by FreeBSD's CVS. Big ugly mess. So I set up a p4 repo, imported DRI CVS's DRM, branched kernel-drm, and changed kernel-drm to match the kernel. Then I made some necessary changes to DRI CVS, imported them to p4, integrated to kernel-drm, realized I needed more changes, and repeated a few times. Each time there would be a conflict or two, usually around the header files, but other than that there was no merging work, unlike the merges from trunk I had tried to do on branches in DRI CVS. Then I took the kernel-drm files, slapped them in the FreeBSD tree and was done. It sounds like if there's some change made by someone in the FreeBSD tree after changes happen in DRI CVS, I can submit it to my kernel-drm branch, import DRI CVS to the dri branch, and reverse-integreate that specific change to the dri branch to commit to DRI CVS. sweet.
Of course, it's a closed-source tool, and has licensing restrictions. However, a FreeBSD committer mentioned that arch looks like a near replacement for p4 at this point. Took a look, and it seems to require some more work than p4 does, but still sounds very similar. Maybe I'll try it for the next project.
I've committed a few tiny cleanups to the DRM, but most of what I've done recently is work on the SiS code. I've got almost all of it changed over to how things work in the post-mesa3.5 world, except for sis_render.c and sis_texture.c, and some of the state change functions. The state change functions are simple -- hooking them in through a different function and changing any references to structure names that have changed since Mesa 3.4. sis_texture.c will be easy, except that it depends on a lot of the render code (for sw fallbacks, etc.). So I'm stuck staring at the render code. There is no documentation for it besides the source and diffs between mesa3.4 and mesa3.5 versions of other drivers. What's got me stuck the most is that this driver is different from the others. i8x0, Radeon, R200, Rage128, and MGA all submit DMA buffers to the kernel, which then get run by the card. The SiS, on the other hand, uses MMIO in the client driver (sis_dri.so) so I can't just steal from r128 for the new render code. I think the closest to what I'm doing is 3dfx, which uses MMIO indirectly through Glide, but Glide hides a lot of complexity in the client driver I think.
Updated the FreeBSD-current DRM to DRI CVS. Also made a port of the 3.0 beta Matrox drivers. I was somewhat disappointed in these -- there is no license file in the tarball itself, so I'm not sure if it's covered by the "license" that's mentioned in the readme that sits next to the file in the ftp directory, or the extremely restrictive generic license most people click through to get to the file itself. If it's the latter it makes a port basically useless, as people have to compile the driver themselves, and doesn't allow FreeBSD to redistribute the HAL which enables some significant features for some cards. Furthermore there were blatant problems in the source itself. There was a #include "/opt/xc.430/programs/Xserver/hw/xfree86/os-support/xf86_ansic.h" and some debugging #defines left around. Makes me question the other unexplained changes between the source included and the stock XFree86 4.3.0 source.