DRI Front Buffer Handling and KMS

Now that I've got rid of my thesis, it's time to dig my teeth into some fun stuff.  I came across a problem with our current DRI architecture for the FreeRunner, which involves trying to combine DRI2 with an existing fbdev-based X driver.  The problem arises because we tell EXA that we will allocate memory for pixmaps ourselves (in this case using our GEM interface through libdrm).  But, in that case, the X server will attempt to allocate the "screen pixmap", by which I mean the main front buffer which contains what's on the screen, with the same mechanism.  This wouldn't be a problem if we could tell, at the time of allocation, that the pixmap being allocated is the screen pixmap, but we can't.  At least, not in the tests I've performed.

The "right" way to make this all work is to use kernel modesetting, KMS, to submit the screen pixmap - at a later time - to the lower-level graphics system for display.  The execution flow goes something like this:

1. Tell EXA we'll handle pixmap allocation.
2. At an unspecified point, the screen pixmap gets created via our mechanism.
3. Later on, we submit the screen pixmap (in fact, just its GEM handle) to KMS.
4. KMS programs the graphics hardware to display the contents of the buffer on the screen.

Currently, we have this:

1. Open /dev/fb0, mmap() it.  That's what's on the screen.
   
2. Tell EXA we'll handle pixmap allocation.
3. At an unspecified point, the screen pixmap gets created via our mechanism.
4. Contents of /dev/fb0 are not the same as the screen pixmap.
5. Whoops.

KMS is really deeper than I (or rather we, thanks to welcome help from Andreas) wanted to dig into the Openmoko graphics system.  Essentially it constitutes a re-writing of the entire kernel framebuffer (glamo-fb) and the X.org driver (since we would need a new driver based on xf86-video-modesetting to take advantage of KMS).  However, there is also a possibility that moving complete control of the graphics hardware to the kernel will help stabilise some things.  At least in the long term.

I took advantage of Truebox's half price deal on debug boards, not knowing how I'd managed to get this far without one.  The kit came complete with screwdriver and guitar plectrum for opening the case (sooo much better than the cheap screwdriver and credit card combination I was using before), and they were kind enough to throw in a spare battery at no extra cost.  Thanks Truebox!