April 2009 Archives

April 27, 2009

Memory Management and Command Queue Handling

My head hurts.

April 23, 2009

Instructions for Glamo DRI

I've written a new page which gives some information about the FreeRunner DRI project, its status, and how to build and install it.

Some of the instructions are also relevant for people trying to get Xorg (without DRI) working on their Neos.

April 14, 2009

SDL and Accelerometer Issues with OpenMooCow

I've heard quite a large number of complaints that OpenMooCow doesn't work with various distributions on Openmoko. Most of these problems aren't directly my fault, but here's a guide to solving them.

If your cow doesn't moo openly, then you should first determine whether you're having an audio problem, an accelerometer problem, or both. Run OpenMooCow from a terminal, via SSH, like this:

$ DISPLAY=:0 openmoocow

You should see some text output ("Moo!") which tells you that a moo has been triggered when you invert your phone, even if you get no sound. If that happens, then your accelerometers are working.

To test the audio without using the accelerometers, simply touch the cow's picture on the screen. If you get a sound, then the audio parts are working properly.

Most commonly, it seems that the SDL packages distributed in SHR (and probably others) try to use the old OSS system for their audio. You therefore need to tell the kernel to enable ALSA's OSS emulation to get audio. You can do this with the following command:

$ modprobe snd-pcm-oss

To make this permanent, do something like this:

$ echo "snd-pcm-oss" > /etc/modutils/snd-pcm-oss
$ update-modules


Additionally, the SDL package distributed by Debian for the FreeRunner has a much larger problem, which there currently isn't any known workaround for. It appears that the sound scheduler callback in OpenMooCow simply doesn't get called by SDL, for no apparent reason.

If you're using version 0.3 (or earlier) of OpenMooCow with a kernel from later than May 2009, the accelerometer readings will be broken due to a change in the way accelerometer data is reported. This is fixed in the latest Git version, which will shortly be tagged and released as version 0.4. SHR-unstable is currently tracking Git HEAD for OpenMooCow, so users of that particular distribution should already have been updated.

Finally, versions up to and including 0.3 have a bug which causes a crash if the accelerometer threshold value couldn't be updated. OpenMooCow sets this to zero to make sure it gets data about small movements of the phone, and restores it afterwards. The sysfs paths changed (again) for recent kernels (see here), and the change triggers this bug. This problem has also been fixed in the recent Git version, and the fix will be included in version 0.4. There are actually two fixes: one to make it aware of the new sysfs paths, and one to fix the crash if the sysfs paths aren't what it expected.

Phew. Who would've thought that such a silly little program could cause so many problems.

Update: OpenMooCow 0.4 now released. See the OpenMooCow page for details.

More Chapman Stick

This is the same performer as in my previous entry, Guillermo Cides, using the same realtime looping technique as before. I liked the tune, and the way it doesn't really finish.  It's like an Escher drawing in music...

April 3, 2009

DRI Locking, DRI2 and glxinfo

Quite a few milestones passed today.  The first was that I finished the writing part of my thesis.  There's still a lot to do, but the main slog of producing the original text is now done.  From this point onwards, it's a question of adding figures and working through the list of feedback from my supervisor.  That's not easy, but it's much easier to get motivated about.  I've really been struggling for momentum recently.

I upgraded my Freerunner's GSM firmware to the "Moko11" version.  This includes some flow control fixes which help with problems such as missed calls.  I wasn't having such problems (at least, that anyone told me about..), but I installed it anyway.  One thing I did notice is that the GSM registration now happens smoothly, whereas previously I'd seen a "no network" icon just before it properly registered.

I ran into an issue with making DRI work on ARM.  The issue is with a locking mechanism which requires an atomic "compare and swap" operation.  On the Freerunner's ARMv4t architecture, that isn't quite available.  The nearest we can get is "atomic swap", which isn't quite enough (see here, for example).  A suitable locking mechanism could be devised (our chip has a SWP instruction for this purpose), but it seemed that this would be at least a moderate pain.

So, with some encouragement from other DRI developers on IRC, I took a closer look at DRI2.  Previously I'd been avoiding this because of the smaller number of drivers which use it, particularly in the realm of simple fixed-function hardware.  However, DRI2 does away with locking altogether, so allows this problem to be circumvented.

I gave this a go, and it turned out not to be too much effort to rebase the work so far against Mesa 7.4 and to enable DRI2.  The result?  "glxinfo" now works with the driver.

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
[snip GLX bits]
OpenGL vendor string: Thomas White
OpenGL renderer string: Mesa DRI glamo 20090402
OpenGL version string: 1.2 Mesa 7.4
[snip OpenGL extensions]
16 GLX Visuals
[followed by the expected list of visuals]
Impressive? Not really, but certainly a step in the right direction.

This is your 22:04 service to mobile Linux 3D graphics acceleration, and the next station will be "glClear".