Rants & Ramblings

A while ago some kind soul sent me a nice little SGI O2, specifically to write a driver for the onboard graphics chip and to make X work. On NetBSD of course.
Now getting the thing to me took a little longer than expected and Jared McNeill beat me to the graphical console driver ( he also ported OpenBSD's audio driver ) but this driver is just a dumb framebuffer console, it plays the same trick as Linux in order to get something resembling a linear framebuffer. The problem with that is it's slow and we can't use the rendering engine since it only operates on a 16x16 array of 64KB tiles, depending on colour depth they're 128, 256 or 512 pixels wide, and 128 lines high. Now the problem with that is that there's no documentation available from SGI itself but I found a rudimentary register description and after a long period of poking around I got the blitter to work. With this crmfb is now a fully hardware accelerated graphical console with all the usual goodies and pretty good speed even in high resolutions.
Getting X itself to work wasn't difficult - it's already built on NetBSD/sgimips and adapting wsfb to the O2's graphics hardware wasn't hard either. There's a big problem though - its native pixel format is RGBA, pretty much all halfway common graphics boards use either ARGB ( the vast majority ) or ABGR ( mostly Suns, a very distant second ). This isn't much of a problem for X itself - the machine independent drawing routines can easily deal with this but xrender doesn't really and there's a lot of software out there which simply doesn't work with the alpha channel in the lowest byte. All Cairo applications for instance just crash. Older applications which use motif or gtk1 usually work though. Others that otherwise work produce slightly off colours ( WindowMaker for instance, text in the menus has a greenish tint when it's supposed to be grey )
Using wsfb obviously depends on the linear fb trick and is completely unaccelerated. So to improve things I started to write a native driver for the graphics hardware. This has the additional benefit that the blitter can convert pixel formats when copying data from a linear buffer to the tiled framebuffer so we can pretend to run in ARGB and get around those xrender issues. This causes another problem though - rendering into the framebuffer isn't going to work because it's tiled and everything expects a linear framebuffer. Fortunately the rendering engine supports quite a few drawing operations and pretty much every compositing operation known to mankind. So I wrote a driver which supports:

• rectangles
  
• screen to screen copies
  
• solid and dashed lines
  
• colour expansion
  
• image uploads
  
• compositing

It turned out that XAA doesn't use image uploads even if they're available in some cases, it always defers some drawing operations to the fb module ( like drawing arcs ) and it's only capable to accelerate a handful xrender operations. To get around that I added some missing functionality to XAA ( use image uploads when available ), don't do and arc drawing at all for now, draw single pixels via hardware and implement my own composite handler so all screen-to-screen or cpu-to-screen xrender operations are done by hardware.
With all this in place xfce4 works just fine, there are a few glitches left ( window backgrounds which are pixmaps aren't always drawn right, this can be seen in galeon for instance ) but things work and especially xrender operations are pretty fast.
The driver can be found here, the hacked libxaa is here.