N9 Scratchbox/Harmattan SDK Install

I'm experimenting with compiling programs for the N9.
Go to http://harmattan-dev.nokia.com and get their python script harmattan-sdk-setup.py. Make it executable:
chmod a+x harmattan-sdk-setup.py
Run the script as root:
sudo ./harmattan-sdk-setup.py
Press "0" for admininstall. This will start a lengthy install. On my machine it started with installing python-qt4. Then scratchbox (89Mb download for X86 and another 89Mb download for ARM). Then comes the SDK itself, one 825 Mb download for the X86-SDK and another 806 Mb download for the ARMEL-SDK.

Now I get:

:~/Desktop$ scratchbox
bash: /usr/bin/scratchbox: Permission denied

That's because the scratchbox install creates a new user group sbox, and adds your username to this group. We now need to log out of the machine and log in again so that this group is created and your user is added to the group. Now we can run scratchbox. Now, from another terminal on the host-machine, start Xephyr with this:

Xephyr :2 -host-cursor -screen 854x480 -dpi 96 -ac +extension Composite &

From the scratchbox terminal we can now start meego:

meego-sb-session start

This gives a little bit of error-messages, but nothing major I guess. And we have a working "phone":

If we start Xephyr in portrait mode instead with 480x854x16 it looks a bit better: (should also work by passing '-landscape' flag to meego-sb-session)

The screen where all the open applications are shown looks a bit strange:

This environment should allow coding and compiling in the correct environment on X86, and then cross-compiling on the ARMEL-target and packaging into debs for sending to the device. But on IRC I am told there's an alternative QtSDK toolchain that does the same thing - maybe in a simpler way. To be continued...

Sunday long run

25k in 2h 40min (avg pace 6:25/km) with avg HR 139. This is about the longest training run I will do in preparation for a marathon - I think. Some training programs advocate increasing the long-run distance up to 30k and above, but many others claim the risk of injury or overtraining increases dramatically when doing 3+ hour training runs and thus they are not worth the risk.

Threading and OpenGL, test 2

Here's a simple test program using LibQGLViewer (screen capture with xvidcap). The vertex array and the index array that OpenGL draws (using glDrawElements) are held in a GLData class which holds a mutex. The Viewer class locks the mutex while drawing, and the worker-thread locks the mutex while updating the data. Here the worker task re-positions the original vertex position, signals the Viewer to draw, and then sleeps for 40 ms. When we don't rotate or zoom with the mouse the frame-rate should thus be 25 Hz. Rotating or zooming causes more frequent re-draws and a higher frame-rate.

To gain any real benefit on a multi-core machine I think the worker thread needs to work on a 'dirty' copy of the data, and we only lock the mutex for a minimal time while swapping in the updated data for the real data. Anyone have any good example code for this? Both a case where the worker produces new data at a slow rate (slower than Viewer re-draws), and at a faster rate should be handled.

Here's an UML(ish) diagram drawn with dia:

Code.

Kerava night Orienteering

4.2km course. Ran about 5.45km in a time of 1h 4 mins.

A bit of a loop when searching for #1. Between #2-#3 there's some unnecessary zigzag. #5-#6 should have probably taken a straighter path on compass heading through the woods to the open clearing (now just ran along paths). Otherwise OK orienteering-wise, but quite slow going in the dark and rain. Would need more courage to run fast in the wet dark slippery conditions...

Multithreaded OpenGL with Qt

I've looked at this example from 2003 and converted it to something that compiles with qt4.7. Here: https://github.com/aewallin/sandbox/tree/master/qt_opengl_threads

Each window is a QGLWidget with its own QThread associated with it that does the drawing. That means the UI should stay responsive despite heavy processing in the threads.

I wonder if this can be made to work with libQGLViewer ?


(The screenshot has caught many windows in the middle of a drawing operation. I couldn't get double-buffering to work. In practice it looks very smooth to the eye.)