Older blog entries for anholt (starting at number 25)

DRI:
Spent the day working on more DRI interface cleanups. This one ties the DRM firmly to a specific device. It should break systems with old X Servers and multiple heads that are DRI-capable in that some heads won't init the DRI, but nothing else. This sort of configuration has been relatively broken anyway, so it's not too big a deal. It removes some ugliness from the DRM, and will make future changes like the lower-level graphics layer more doable. Also, the DRM no longer offers a service of getting the irq of any pci device (now it's restricted to just the device the DRM is attached to), and the ioctl to install the irq handler no longer cares about the irq number that was set if the interface version is set high enough (1.2).

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.

kdrive:
libdrm is compiling, and I've got libdri and a DRI-converted r128 driver that need to be made to compile now. For now it's almost all just direct copies of XFree86 code (sometimes with bits chopped out). I know there's a lot more compatibility junk we can remove, but the first thing is to get some drivers working.

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.

DRI:
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

DRI:
Continued work on my sis6326 DRI driver. I'm really close (well, closer than before those bugfixes), but triangles still aren't being drawn. It's frustrating, but I've been staring at that code for so long I think a break might be called for.

xlibs:
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.

kdrive:
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.

SiS:
More work on the SiS 6326 DRI driver. Hardware clears/swaps appear to be working. Unfortunately, triangles aren't being drawn, and I can't find any major differences in the triangle code compared to utah-glx. Maybe I'm doing some setup wrong somewhere.
DRI:
I think we've got the linux radeonfb+radeon basic issue almost fixed (there's a breakage on 2.6, which I hope another committer will commit his fix for this weekend). There are still other issues before the DRM can be a proper linux driver, many of which are actually similar to the issues for the DRM to be a proper FreeBSD driver. I'm pretty excited to hear this, as I had previously assumed it was just something about how linux does things. I think a lot of things have been changed between 2.4-2.6 to make drivers much more similar in some ways to FreeBSD drivers.

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.

kdrive:
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.

DRI:
A few days of wild DRI hacking. Implemented a DRM interface version ioctl and a change that required a version bump of the DRM interface. It's a small part of my evil plans to make this kernel device driver actually (gasp!) attach to a specific device.

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.

DRI:
Committed my SMPng locking code for FreeBSD. It's taken a while, and I'm still not 100% sure of it, but it will have time to get a shakedown before Giant is actually removed. However, it should deal with missed IRQ issues on -current, which were my fault for not understanding locking issues before. I also expect that it may have slightly less overhead than before.
FreeBSD:
The joy of unreproducible bugs. I've had a few problem reports about hangs with the DRI, particularly with Radeons, on FreeBSD-stable. I thought I had a patch to fix it, but when I put a radeon in my testbox I couldn't reproduce the problem on -stable. A user on IRC just asked me about the same problem, and when I gave him the patch it fixed it. Now it's off to the release engineers so it can make it in for 4.9-RELEASE, but I'm frustrated I didn't get this fixed a month or so ago when I first got that patch and had these problem reports.
DRI:
Apparently my Mesa diff got committed while I was away on fall break, which was nice. Did a lot of DRM work the last couple of days. Committed my variation of the patch to make the DRM for Linux probe based on PCI IDs, and reorganized the IRQ handler code into a new file so it can be used for SiS and 3dfx vblank syncing. Updated my SMPng locking diff for the latest DRM code and submitted it for review to FreeBSD-current. Now I need to add vblank syncing for SiS and 3dfx, both of which I think I have sufficient specs for.
SiS:
Neat. What I thought might be a hardware limitation (~1.5 bit error with 32-bit depth buffer in glean's readPixSanity test) has its root in Mesa casting the depthbuffer clear value, a double, to a float then back to a double. Submitted a patch for it. Cleaned up the fog code greatly by removing choosing the CHEAP fog mode which wasn't cheaper and was actually uglier. Nearly fixed the glean maskedClear test, but for the doublebuffered context case the back buffer clearing sometimes doesn't work right, and the bug seems to rely on the state of the hardware before the running of glean. Fun.

16 older entries...

New Advogato Features

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!