Worked on my hook for the "(ARGB8888 IN A8) OVER screen" composite, one of the common ones in xcompmgr. It (as will be the case for most hardware) will be implemented using the 3d hardware and treat the pixmaps as textures. What appears to be required for most operations (xcompmgr's operations included) is non-power-of-two textures, wrapping for POT textures at least (for 1x1 textures), two texture units, and the standard GL_BLEND-type alpha blending. I suspect more ops could be accelerated using more complicated texture blending instead of GL_BLEND, and I would bet the NPOT texture requirement could be avoided by using scissoring. Anyway, most of the 3d setup is done, and I just need to set one more register and then write code to actually emit vertices. I hope. :-)
Note that this doesn't cover trapezoid acceleration, which is something that will be used by many consumers of Render (cairo, for example). It's just to get some of the very common uses at the moment (AA text and xcompmgr) accelerated.
Applied the patch from Michel Daenzer I had worked on for fbdev backend in Xati. It's a little unstable for me when I have fbdev loaded, but I've heard rumors there are issues with radeonfb on 2.6.0-test
I'm stuck in the FreeBSD port of the kdrive server. I'm getting a panic in vm86 mode when using VM86_INTCALL, which I was hoping would be the easy solution. I don't understand how to use the normal VM86 mode in this situation, either.
Issues that I know of with it, hmm. Radeon with acceleration and 1400x1050 mode doesn't work right because of limitations in pitch -- we need to do our own mode setup (hopefully we can figure out how to do that in a clean manner) or use radeonfb for that. Lacks render accel (need help from keithp for infrastructure). Lacks xv (needs to be done using 3d hardware instead of overlay). Hardware cursor not supported (insignificant, at least with standard X cursors). Doesn't use the DRM. The DRM is my next task, fixing up that poor r128drm code I had done to be used with Xati. I have this hope, and I think it's pretty realistic, that a lot of code can be shared between r128_dri.c and radeon_dri.c, so I can have a single ati_dri.c.
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.
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!