This means that I've got libdri (minus its glx bits which are ifdeffed out until we get glx) compiling along with libdrm.
The next major step is GLX (well, after getting this driver to actually run :-). I'm really torn about how to go about this. The easiest and most immediate way will be to bring in Mesa and do it just like XFree86 does but without the loadable GLcore. Better would be for GLcore to be buildable outside of the xserver tree and dlopenable. Best would be to either have the server dlopen a DRI driver (perhaps the fb driver) and use that for GLX rendering, or to have the server fork a program that handles GLX that the server hands off to it which then renders using a dri driver. I can see the merits of both of the last two. But I think I'll end up doing the first one first.
Continued work on xlibs ports. All but 3 (Xi, Xcursor, another I don't recall ATM) have been ported and I'm using them on my desktop. Forwarded the ports to the new x11@FreeBSD.org mailinglist which I got created to hopefully bring other people into X11 maintaining on FreeBSD so I can spend less time being frustrated with XFree86. One of our major ports PR busters has been talking about working on a kdrive port to FreeBSD.
I've moved the DRI client drivers into a separate port. Hopefully soon they'll be provided by Mesa, but it'll at least make letting users upgrade to CVS DRI drivers much cleaner. Also removes a decent bit of mess from XFree86-4-Server. I'm doing a test now of XFree86-4-Server using freedesktop.org shared X libraries rather than building and linking those libraries in statically (this occurs for 4 of the servers). I've done some cleanup bits in the freedesktop.org xlibs, and I'm looking forward to rolling releases of some of them and integrating them into FreeBSD soon.
Got a bug report from my first DRM interface change, about running two servers on different VTs on a single card, with both trying to enable the DRI. The set/getunique system which I deprecated the "set" half of in the 1.1 interface acted as a sort of lock preventing a second server from (re-)initializing the DRM. The removed "set" attempt let the second X Server partially initialize the DRM before it failed. In the process the kernel would become confused about where the lock was. So, I made it not allow a second lock-containing SHM area to be added, which locks out the 2nd X Server before it messes things up.
Played around in the PR database a bit. Closed some kern and i386 PRs, mostly due to them being already fixed. Fun to see myself shoot up to #12 of the non-ports PR busters on the PR stats page.
The nice part is this change doesn't even mean any modifications to the X Server, though it'll remove some code from the kdrive DRI implementation I'm working on since I'm going to insist on up to date DRM for that.
As a quick explanation of these parts: libdrm is a userland API for talking to the DRM. libdri includes both the DRI* API and the XF86DRI extension. However, this does not mean "DRI in kdrive" yet as people might think -- we need GLX and I'm sure a lot more work on libdri before we can have hardware-accelerated 3d.
Nobody's stepping up to do the creation of a lower-level kernel driver for the DRM and framebuffer to share (as far as resource allocation, perhaps DMA/IRQ handling) on Linux. It really needs to happen, and Linus and many others agree. Unfortunately, there are very few people who want to work on this sort of stuff, so I may end up having to do it myself. I think my track record on my last commits to the Linux DRM should warn a real Linux kernel hacker to do it first. :-P
I'm planning on making the freedesktop.org xlibs the ones used on FreeBSD instead of XFree86 where possible. I've pointed out a couple of problems and fixed a couple of bugs. And committed fixes myself.
Finally successfully installed debian-unstable as my netboot system so I can work on kdrive. Got the r128 server working after swapping out a bad mouse (which FreeBSD also hates), and fixing scissor setup on the r128. Now I'm working on getting libdrm integrated so 2d drivers can be written using the DRM.
Merged the DRM to FreeBSD CVS, which revealed one bug (fixed now), but also apparently fixed at least one bug that's been around a while. Now there's just one last bug with KDE, but that one's going to take some doing to squash.
I haven't been this excited about a project in a long time. From his descriptsions, Keith Packard's experimental X Server project is doing a lot of things right. It won't have anywhere near the hardware compatibility that XFree86 does, but I'm willing to accept that if we can make a maintainable X Server which implements features that have been demanded for ages, in a clean manner. My main interest is getting it running on FreeBSD (this is going to require packaging up a lot of the fd.o xlibs packages, which I want to do anyway, and at least vm86 support for bios calls), getting glx in it, and maybe DRI if I can squeeze the time in between working and doing the minimal amount of studying.
It required as its basis a diff from another committer to have the linux DRM probe based on PCI IDs. That one ran into troubles because pci_driver type attachment is exclusive. So, if radeonfb had attached to your radeon, the DRM didn't get a chance to. Using old-style attachment it shouldn't be an issue, though. Given that I just changed the DRM over to old-style attachment on linux, I sure hope so.
DRI/DRM plans for the next week or so include vblank syncing support for 3dfx and/or sis, 64-bit cleanliness in the sis interfaces, lobotomizing some of the ioctls that are related to the DRM not being attached to a specific device, and merging the DRM to FreeBSD-current.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!