Older blog entries for anholt (starting at number 29)

kdrive:
Driver in a day. I took the r128 driver from andersca and tried to make a SiS 300-series driver for kdrive. I'm close I feel, but nothing's being rendered yet. I got frustrated, so I decided to try a Radeon driver. Surprise, it was really easy, and taking code from XFree86 I got it working within a few hours. Then I noticed that Rage 128's 2d acceleration was very, very similar to that of the Radeon, so I added Rage 128 support to it. Now we've got an "ati" accelerated kdrive driver that supports both. It's got some limitations (broken at non-16-bit, like the previous r128 driver, and lacks all but two Rage 128 PCI IDs), but I'm pretty satisfied.
18 Nov 2003 (updated 18 Nov 2003 at 08:23 UTC) »
kdrive:
Got my DRM-using Rage 128 driver to the point of compiling, at long last. Most of the changes have been tons of tedious mechanical changes and grabbing bits from XFree86. In the process I've noticed a good bit of code that I expect to send to the chopping block (since I don't intend us to ever support the gamma DRM in its current incarnation). And maybe a bug, which would be a bug I've experienced before, but I haven't verified (lack of DRIMoveBuffers for r128). At this point it initializes the DRM, but there's some failure in int10. Note that not understanding int10 is the reason I don't have xserver on FreeBSD yet.

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.

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

FreeBSD:
Spent the day chopping XFree86 up into little bits. Boy, is it satisfying.

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.

DRI:
Committed my DRM interface 1.2 change. It ties the DRM down to a specific device, which will make making a lower-level DRM layer much more sane. I have more evil plans, such as not allowing the X Server to addmap/map FB or MMIO areas that don't correspond to the areas that the card advertises through PCI. This will work well with the standalone Mesa and kdrive desires that the DRM tell userland where the FB/MMIO are, rather than the other way around.

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.

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

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.

20 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!