Disabling Raspberry Pi Cursor (Inside X11/Xorg)

In several Raspberry Pi configuration (usage scenario), the presence of cursor is not wanted. Therefore, removing the cursor from the X server is desired. This link explains various ways to disable the cursor (not merely showing a transparent cursor but disabling it altogether).

I'm using the default Raspbian distribution. Therefore, the default window manager is LXDE, managed through lightdm. Lightdm configuration file which dictates how the X server starts is /etc/lightdm/lightdm.conf. In order to disable the cursor, you have to invoke/starts the X server with the -nocursor argument, or other means as explained in the link above. I decided to go with X -nocursor command to start the X server. This is accomplished through editing the /etc/lightdm/lightdm.conf file. Find the line which starts with xserver-command and edit it to start the X server without cursor. In my particular case, the line is located right below the [SeatDefaults] group of "options". This is how it looks like when I'm done (the ellipses means lines in the file which are ignored):

...
[SeatDefaults]
xserver-command=X -nocursor
...

With the modification above, the cursor is gone, once I restarted the X session.
Hopefully this helps those who need this kind of Raspberry/Raspbian setup.

Moving Raspberry Pi logs and temp files to RAM

This link explains how to move your temporary files from secondary storage device (HDD, SDCard, SSD, etc.) to RAM in general--seems to be the link no longer working. I did a similar thing with my Raspberry Pi because the temporary files are not of interest in my particular setup. The difference lays in the details because of limited RAM space in Raspberry Pi, I decided to limit the amount of RAM for the temporary files to 5MB at most. This is how my Raspberry Pi /etc/fstab looks like (the snippet below only shows relevant lines for the temporary files setup):

tmpfs    /tmp        tmpfs      defaults,noatime,mode=1777,size=5m    0    0
tmpfs    /var/log    tmpfs      defaults,noatime,mode=1777,size=5m    0    0
tmpfs    /var/tmp    tmpfs      defaults,noatime,mode=1777,size=1m    0    0

The  "size=5m" and similar parameters force the RAM size used for the corresponding temporary file to certain megabytes. The "m" suffix corresponds to "mega bytes". The details are explained in this link.

I have tested my Raspberry Pi with several reboots and cold start and everything works without a hitch.

Update:
---------
I need to increase the amount of RAM dedicated to /tmp to 5MB after zeromq and nanomsg build (compilation) failure happened when /tmp was still 1 MB. This is due to gcc places the intermediate compilation result (i.e. the expanded asm code + macros) in /tmp before linking takes place. It seems some of the code expands to > 1MB of size. After changing /tmp to use 5MB of RAM, everything worked without a hitch.

Analyzing Multithreaded Code Mathematically

Multithreaded code is hard to debug. Therefore, it helps a lot if one can analyze it mathematically to see whether the code is sound or not.
There are at least 3 approaches to do that:

1. With Petri-Net (http://en.wikipedia.org/wiki/Petri_net)
2. With CSP (http://en.wikipedia.org/wiki/Communicating_sequential_processes)
3. With Pi-Calculus (http://en.wikipedia.org/wiki/%CE%A0-calculus).

I have just started to learn all of them, so I cannot explain the pros and cons of each one of them just yet.

Math Link(s) for Programmers

I found this page by Ken Ward really interesting and useful for programmers trying to analyze the algorithm in their code or other people's code.
Particularly the pages on treatment of series. I found some of the proofs for sum of squares and other series to be particularly eye opening. Take the explanation on sum of squares using infinite calculus for example. I didn't know that it's possible to do that before :P.

GTK3 Image Scaling on Raspberry Pi Hiccups

If you read my previous post on GTK3 image scaling, you'll notice that GTK3 uses Cairo for the task. I compiled and tested the code on Raspberry Pi (B revision) but unfortunately the lag is noticeable, on the order of 1 second or more on 1366x768 LCD display. This is quite unacceptable for some "display-intensive" applications.

Anyway, this is without using any acceleration on the Pi's GPU because I have yet to make that works. I noticed a sort of GPU accelerated sample codes in the /opt directory on Raspbian but unfortunately, I have yet to be able to run the sample code successfully. Compiling the code runs just fine without problems but running the result always failed.

Image Scaling in GTK 3 (with Cairo)

GTK 3 differs significantly to GTK 2 in the image rendering department. In GTK 2, image rendering is handled by GDK via GdkPixbuf. On the other hand, GTK 3 moves almost all of the burden to Cairo. This could be rather confusing to GTK newbies.

This post explains how to carry out image scaling with Cairo via a GTK 3 sample application. In GTK 2, this is a relatively simpler task via GDK. You should consult this, if you want to do image scaling in GTK 2.

Now, let me go straight to the sample code. The makefile for the code as follows:

all:
 gcc $(shell pkg-config --cflags --libs gtk+-3.0) cairo_test.c -o cairo_test

clean:
 rm -vf *~ cairo_test

The makefile assumes that the (single) source code file is named cairo_test.c. Now, let's proceed to cairo_test.c.

#include <cairo.h>
#include <gtk/gtk.h>


static void do_drawing (cairo_t *, GtkWidget * widget);

struct
{
  cairo_surface_t *image;
} glob;

static gboolean
on_draw_event (GtkWidget * widget, cairo_t * cr, gpointer user_data)
{
  cr = gdk_cairo_create (gtk_widget_get_window (widget));
  do_drawing (cr, widget);
  cairo_destroy (cr);

  return FALSE;
}

static void
do_drawing (cairo_t * cr, GtkWidget * widget)
{
  gfloat screen_width;
  gfloat screen_height;
  gfloat image_width;
  gfloat image_height;
  gfloat x_scaling;
  gfloat y_scaling;

  /* Display screen dimension in console  */
  screen_width = gdk_screen_get_width (gdk_screen_get_default ());
  screen_height = gdk_screen_get_height (gdk_screen_get_default ());
  g_message ("Screen width %f", screen_width);
  g_message ("Screen height %f", screen_height);

  /* Scale the loaded image to occupy the entire screen  */
  image_width = cairo_image_surface_get_width (glob.image);
  image_height = cairo_image_surface_get_height (glob.image);

  g_message ("Image width %f", image_width);
  g_message ("Image height %f", image_height);

  x_scaling = screen_width / image_width;
  y_scaling = screen_height / image_height;

  g_message ("x_scaling %f", x_scaling);
  g_message ("y_scaling %f", y_scaling);

  cairo_scale (cr, x_scaling, y_scaling);

  cairo_set_source_surface (cr, glob.image, 0, 0);
  cairo_paint (cr);
}

static void
load_image ()
{
  glob.image =
    cairo_image_surface_create_from_png ("resources/quake_3_arena.png");
}

static void
draw_mark ()
{
  cairo_t *ic;
  ic = cairo_create (glob.image);
  cairo_set_font_size (ic, 11);

  cairo_set_source_rgb (ic, 0.9, 0.9, 0.9);
  cairo_move_to (ic, 100, 100);
  cairo_show_text (ic, " 343 Industries 2013 , (c) Pinczakko ");
  cairo_stroke (ic);
}

int
main (int argc, char *argv[])
{
  GtkWidget *window;
  GtkWidget *darea;
  cairo_t *cr;

  load_image ();
  draw_mark ();

  gtk_init (&argc, &argv);


  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

  darea = gtk_drawing_area_new ();
  gtk_container_add (GTK_CONTAINER (window), darea);

  g_signal_connect (G_OBJECT (darea), "draw",
      G_CALLBACK (on_draw_event), NULL);
  g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL);

  gtk_window_set_position (GTK_WINDOW (window), GTK_WIN_POS_CENTER);
  gtk_window_set_title (GTK_WINDOW (window), "Cairo Test");
  gtk_window_set_decorated (GTK_WINDOW (window), FALSE);
  gtk_window_fullscreen (GTK_WINDOW (window));


  gtk_widget_show_all (window);

  gtk_main ();

  cairo_surface_destroy (glob.image);

  return 0;
}

In the code above you can see I'm using a file in the resources directory, with name quake_3_arena.png as the image to be loaded and scaled to the dimension of the entire screen (full screen). The image scaling and drawing happens in the "draw" event handler function.

You should pay attention to call cairo_paint() right after setting the cairo surface to draw into. In this case, the code calls cairo_set_source_surface() to do that in do_drawing() function. The code above is based on a modified code from this tutorial. The code displayed above, reads a PNG input file and then scale the image to the dimension of the screen before displaying it. The code also superimpose a "watermark" on the image by using the draw_mark() function.

Testing on Raspberry Pi with 1366x768 pixel display shows that Raspberry Pi is not quite up to the task when the image on the screen is repeatedly redrawn (for example when juggling between windows with Alt+Tab). In this particular case, the lag is noticeable before the scaled image is shown, could be up to 1 second.
I'm still evaluating whether or not 2D acceleration is enabled or not. Because I think Raspberry Pi have enough horsepower for the task (without the 1 second delay) of 2D acceleration is active.

Autostart X Application in Raspberry Pi

Assuming that you're using the official Raspbian (mine is "wheezy") image, the default Window Manager is LXDE. Therefore, to enable an X application to start automatically once X started, you would consult LXDE documentation. This is the direct link: http://wiki.lxde.org/en/Autostart.

What basically you should do is create a directory named autostart inside ~/.config. Here, the ~ means the home directory of the account that log-in directly to X. Then, in the autostart directory, create a *.desktop file and make it executable (chmod +x [your_file].desktop). The format of the *.desktop file as follows:

[Desktop Entry] 

Type=Application

Exec=your_application_path_here

That's it.

Anyway, some other useful links:
https://wiki.archlinux.org/index.php/LXDE#Autostart_Programs
http://blog.flowbuzz.com/2012/07/raspberry-pi-and-autostart.html
http://wicd.sourceforge.net/moinmoin/FAQ

What Happened in Mali?

I was quite surprised to read the news on France involvement  on the "internal" Mali troubles with "rebels" and "supposedly terrorists". Common sense would of course ruled that action as probably "useless" and waste of taxpayer money. But, well, not exactly if you dig deeper though.

The first hint comes from "the conflict" happens in the North of Mali (http://blogs.defensenews.com/intercepts/2013/01/photo-of-the-day-jan-15-2013/). What the hell is there in the "North"? Call me conspiracy theorists. But, if you look at this: http://www.oklouranium.com/, you'll notice that there is an uranium ore mine to the northeast of Mali. Are these guys fighting for Uranium? Well, that link shows that the company mining the uranium is from Australia, instead of France. But, if that
mine falls to the "rebels" hand, that would be a VERY big trouble. I'm quite sure there is black market for uranium and also there's demand of course. Another interesting fact is Mali has a quite big gold deposit (12th) in the world and 3rd in Africa. The fact is mentioned in the previous link. This is interesting nonetheless. If the rebels could control access to the gold deposit, they could probably fund themselves adequately.

Another issue in Africa lately is the feeling of unease in the West as China encroach into Africa and making big inroads, trying to secure raw materials in an area traditionally "controlled" by European countries. Well, maybe I'm thinking too much into this. But, I think it's just common sense. Any industrialized/semi-industrialized Nation or let's groups of people would have demands for raw materials. The problem is, if the material is as dangerous as uranium, that would be troublesome.

Tutorial on Writing GTK+ Mutithreaded Application

I've been looking for some nice tutorials on GTK+ Multithreaded Applications for a while. I think these are the most representative on the web at the moment (at least for newbies like me):
http://blog.borovsak.si/2009/06/multi-threaded-gtk-applications.html
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness
and also this thread on gnome mailing list:
https://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00137.html

Interprocess Communication with DBus in GTK Applications (for Beginners)

This post is meant to provide pointers to where to start developing with GTK application that use DBus as  its inter-process communication platform.

Beginners starting to program DBus in GTK applications surely rather frustrated by the lack of up to date tutorials out there. Fear not, there's  actually a lot of sample codes and tutorials in the glib2 source code distribution! Albeit not exactly for real beginners. You should still read the DBus tutorial over at http://dbus.freedesktop.org/doc/dbus-tutorial.html to understand the concepts. It's impossible to understand the glib wrapper (in the GIO part of glib)  unless you understand the DBus concepts.

I'm using Slackware 14 at the moment. So, naturally, glib2 source code is in the second DVD in the l (library) package series. Mine is glib-2.32.4. The documentation related to DBus in Glib is under the GIO section because GIO is the part of Glib which implements the DBus bindings. If you have download glib-2.X source code, the documentation for the Glib DBus binding (GDBus) starts in the glib-[glib_version]/docs/reference/gio/html/index.html file. You'll be able to browse through all of the GDBus info from there, such as GDBusConnection, GDBusMessage and so on.

Now, for beginner, having a sample dbus server and client that actually works is of utmost importance. No problem, head over to glib GIO documentation over at http://developer.gnome.org/gio/2.29/GDBusConnection.html (Note: This is the online version of the GDBus binding documentation I mentioned in the previous paragraph). Scroll down to Example 2 (D-Bus server example), this is the DBus server source code. Now, for the DBus client, scroll down to Example 4 (D-Bus UNIX File Descriptor example), this is the DBus client source code.

Now, let's name the DBus server source code dbus_server.c and the client dbus_client.c. This is the Makefile I used to build both sample code:

all:
 gcc $(shell pkg-config --cflags --libs gtk+-3.0) dbus_server.c -o dbus_server
 gcc $(shell pkg-config --cflags --libs gtk+-3.0) dbus_client.c -o dbus_client

clean: 
 rm -vf *~ dbus_server dbus_client

Just invoke make to build them all in your shell. I made some changes to the DBus server code to display verbose logging in the shell. These are the changes:

77,78c77,78
<                                                  "As requested, here's a GError not registered "
<        "(G_IO_ERROR_FAILED_HANDLED)");
---
>                                                  "As requested, here's a GError not registered 
> (G_IO_ERROR_FAILED_HANDLED)");
85,86c85,86
<                                                  "As requested, here's a GError that is registered "
<        "(G_DBUS_ERROR_MATCH_RULE_NOT_FOUND)");
---
>                                                  "As requested, here's a GError that is registered 
> (G_DBUS_ERROR_MATCH_RULE_NOT_FOUND)");
160,161c160,161
<                                                       "Your message bus daemon does not support "
<             "file descriptor passing (need D-Bus >= 1.3.0)");
---
>                                                       "Your message bus daemon does not support file 
> descriptor passing (need D-Bus >= 1.3.0)");
298,299d297
<   g_printf("Timeout reached! \n");
< 
339,340d336
<   g_printf("DBus \"bus\" acquired! \n");
< 
361d356
<   g_printf("DBus \"name\" acquired! \n");
369,370d363
<   g_printf("Connection to DBus lost!\n");
< 
398,399d390
<   g_printf("Entering g_main_loop_new() ..\n");
< 
403,404d393
<   g_printf("Leaving g_main_loop_new() ..\n");
< 
411,413d399
< 
< 

They're not major changes, just to log where the execution is in the server code at runtime.

Screenshot time.. This is how it looks like when I run the DBus server and then the DBus client shortly thereafter. The screenshot is taken on the shell that runs the DBus server.

Mind you that this is Glib 2.0 used in GTK+3.0 or above, not GTK+2.0! Also, you should run the applications under X11, otherwise they will not be able to connect to DBus because the required glib2 library call failed. This is because in most Linux distribution, the GDK library--which GTK depends on--is built with X11 back-end. You can check this dependency with the following command:

me@my_machine:~/$ pkg-config --cflags --libs gdk
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -lgdk -lXext -lX11 -lm -lglib

As you can see, the output of the command in my machine shows dependency to X11, namely in the -lXext -lX11 linker parameters.

Anyway, you could actually watch the DBus "messages" in real time as the exchange from the server and client application happens with dbus-monitor. Just run dbus-monitor in another shell before you run the client. You could filter out unwanted messages from showing-up with dbus-monitor options.

Well, hopefully this is enough to help those poor souls looking for DBus and GTK beginner's guide out there.