GTK+ Development for Raspberry Pi

After developing GTK+ applications (to run on Raspberry Pi) for more than 2 months, I found that it's much more productive to do most of the development and preliminary testing on my laptop. Once I'm done with the preliminary tests, I transfer the code to Raspberry Pi for native compilation. Most of the time the code runs without a hitch but in several rare occasions, I did find some minor bugs on my code once the code runs on Raspberry Pi. This is one BUG example:

...
GError *error;

// Function that uses "error" variable here
...

The code above runs just fine on my laptop (x64 Linux), but it terminated the program execution in Raspberry Pi complaining that the error variable is not initialized properly. This is the fix:

...
GError *error = NULL;

// Function that uses "error" variable here
...

Simply initializing the variable to NULL makes everything works as expected :-). There are other minor differences, but from what I have code, I can say that even multithread and multiprocess (running child process) code works just fine in Raspberry Pi when using GTK+v3.X (with the accompanying GLib, etc.). Testing the application on the laptop, most of the time mirrors the behavior of the code on Raspberry Pi.

The reason I'm doing this kind of development is simply time. It takes too much time to compile and test the application on Raspberry Pi. The code-test cycle on my Laptop is far faster and more productive. I hope this is also a consideration for those developing GTK+ application for Raspberry Pi.

Raspberry Pi Hardware Support for Thread Synchronization

Hardware support for synchronization in multithreaded application could improve its execution time and responsiveness. The synchronization primitives mostly available in the form of atomic Compare-and-Swap instruction. On x86/x64 architecture, the instruction is called CMPXCHGXX which stands for compare-and-exchange (the XX is only a placeholder because there are several variants of the instruction). On ARM architecture, the support is in the form of the SWP (swap) instruction.

Raspberry Pi CPU supports the SWP instruction. You can see this when you "cat /proc/cpuinfo" as follows:

pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000f
Serial          : 00000000231c08f2

As you can see, the swp instruction exist in the BCM2708, the CPU on the Raspberry Pi SoC. Therefore, we could expect that multithreaded application ported from the PC (x86/x64) could seamlessly ported to Raspberry Pi with expectation that the synchronization primitives would work with the help of the hardware (via swp instruction). I have yet to do some tests on this. It should be on the next post on the Raspberry Pi subject.

Autostart (Single) Fullscreen X Application in Raspberry Pi

This post is a continuation of my previous post (http://darmawan-salihun.blogspot.com/2013/01/autostart-x-application-in-raspberry-pi.html). Here I talk about making the previous setting into a system-wide setting, i.e. an X application that would be started regardless of the X login used.

The related details are in this link. Assuming you're using Raspbian, you should edit  [/etc/xdg/lxsession/LXDE/autostart] file to add the application that you want to be started right when X starts. The contents of the autostart file should look similar to this:

@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@xscreensaver -no-splash
@[your_x_application_absolute_path_here]

As you can see above, replace the place-holder (your_x_application_absolute_path_here) with the absolute path of your application (minus the brackets of course).

If you are in the final stage of customizing your Raspbian system, probably you want to get rid of everything running in X except for your own X application. In that case, you can remove the "@lxpanel --profile LXDE" line to remove the panel(s) altogether, because in default setting, the panel would be shown in the lower part of the screen (display). This is probably something you want to get rid of if your X application is a fullscreen X application.