Building the Moblin Media Player Gui with the Intel Compiler

Introduction

The media player project is know as Hornsey and depends on clutter, clutter-gst, bickley, nbtk, bognor-regis, libunique, libstartup-notification and gtk+-2.0.

For the build enironment I am using the Moblin2 development image installed on a dualcore laptop. 

In this paper, I am only building the top level of the player, and not the underlying library dependencies.

Setting up the build environment 

Download and install the moblin dev image from here

http://moblin.org/documentation/moblin-sdk/download-development-images6

Create a USB or CD and install. Instructions here:

http://moblin.org/documentation/test-drive-moblin/using-moblin-live-image

Building the media player gui

Downloading the sources

Boot up Mobln2

In directory of your choice get the Hornsey code

    git clone git://git.moblin.org/hornsey

Directory structure should look similar to this:

    <dev dir>/hornsey

Go into the hornsey directory and change the branch to match  the moblin dev image
e.g.  

         cd hornsey
         git checkout –b origin/moblin-2.0

 FYI you can get a list of branches by doing
      
        git  branch –a
 

Building the sources

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=~/dv/hornsey/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc
    export CFLAGS="-02 -g"
 

   export PREFIX=~/dv/hornsey/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

      config.status: config.h is unchanged
      config.status: executing depfiles commands
      config.status: executing default-1 commands
      config.status: executing po/stamp-it commands
      Now type `make' to compile hornsey

Now build the source by calling make

       
        make clean

        make

The progress of the make will be reported, the last few lines looking similar to this:

          CC    hrn-controls.o
          CC    nbtk-im-label.o
          CC    hornsey
        Making all in data
        Making all in po

Installing the media player

To install the new new media player call:

      make install

Checking the contents of the install dir :

ls -R  $PREFIX

    /home/sblairch/dv/hornsey/gcc:
                bin  share

    /home/sblairch/dv/hornsey/gcc/bin:
                hornsey

    /home/sblairch/dv/hornsey/gcc/share:
                applications  dbus-1  hornsey  icons  locale

Running the Media Player

The media player can be invoked by simple calling the executable  <install dir>/bin/hornsey

Introduction
Intel offers a wide range of software development tools designed for enabling the software developer to get great performance and end-user experience out of their application. At the same time it ensures with its wide range of development tools that performance bottlenecks can be identified quickly and coding errors and runtime issues can be pinpointed and fixed quickly. The purpose is to enable on-time delivery of mature and fast applications that showcase the user-friendliness, performance and feature richness of your applications.
Specifically for development projects targeting Moblin compliant applications and devices taking advantage of the Intel(R) Atom(TM) processor a set of software development tool suites is being offered. It bundles key development components addressing all phases of development from design, testing, bug fix cycle to performance tuning.
The following paragraphs will provide an insight into the Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) processor and the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) processor. They will highlight the tools components included and their effective use.

Tools Overview
The Intel(R) Atom(TM) processor is specifically targeted at low-power IA-32 based designs for a wide range of small form factor devices. These include netbooks, settop boxes, consumer electronics, in-vehicle infotainment and other designs focusing on internet content consumption, telephony and mobile location based services. The one thing most of these designs have in common is that their form factor makes it inconvenient to develop software natively on these platforms. The Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor take this into account and offer solutions that address cross development requirements for designs running Moblin compliant Linux* OS and other Linux* based operating systems.
The Intel(R) Application Software Development Tool Suite consists of 4 development tools components.

Intel(R) C++ Compiler
The Intel(R) C++ Compiler for Linux* has been optimized to harness key properties or the Intel(R) Atom(TM) processors architecture and get optimal performance out of it. The option switch –xSSE3_ATOM will cause the Intel(R) C++ Compiler to model the instruction pipeline of this in-order processor feeding instructions to it in an order that minimizes dependency stalls and resource stalls. Additionally it takes advantage of a complex set of heuristics to decide which type of assembly instructions to generate to speed up memory access, improve branch prediction and take account of the Intel(R) Atom(TM) processor’s floating point properties. Finally it also aggressively takes advantage of the SSE3 instruction set for vectorization and sped-up execution of thus parallelized loops.

Intel(R) Integrated Performance Primitives
The Intel(R) IPP offer a rich set of library functions and codecs to be used to speed up development of highly optimized routines for the handling of multimedia formats and data of any kind. They have been low-level hand optimized to provide their known performance strength and ease of use for Intel(R) Atom(TM) processor based platforms.

Intel(R) VTune(TM) Performance Analyzer
Finding the bottlenecks in your application, identifying where most time is spent during application and using event-based sampling to find hardware resource constraints that limit the performance potential of your application. This is the domain of the Intel(R) VTune(TM) Performance Analyzer. A VTune(TM) Performance Analyzer Sampling Collector (SEP) is included that allows for low overhead command line based performance data collection on the Intel(R) Atom(TM) processor based target device without any instrumentation of the code base to be analyzed.

Intel(R) Application Debugger
A rich and user friendly Eclipse* RCP based graphical user interface combined with OS signal awareness and thread awareness enable the developer to use this TCP/IP cross-debug solution to more easily find coding issues that affect application runtime behavior and correct them.

Intel(R) JTAG Debugger
In addition to these components the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) processor provides a JTAG debug solution that utilizing the same Eclipse* RCP based graphical user interface to give you access to the descriptor tables, page tables and all chipset registers with the detail that only it’s bitfield editor can provide. This debugger allows for high level language source level debugger of bootcode, OS kernel and device drivers.

Benefits for your development projects
The benefits of using these comprehensive tool suites are many and impact every phase of the software development process.

Improved performance in your critical applications and codecs due to the use of the Intel(R) C++ Compiler’s optimizations for the Intel(R) Atom(TM) processor or the Intel(R) IPP.

Performance tuning and avoidance of inefficient code in your application with the help of the Intel(R) VTune(TM) Performancer Analyzer, leading to a smoother and more responsive end-user experience

Faster coding issue detection and correction and thus improved maturity as well as faster time-to-market, faster development cycles for your project.

How to start with application development for Moblin on Intel® Atom™ processor
The Intel(R) Application Software Development Tool Suite supports a wide variety of Intel(R) Atom(TM) processor based devices. This means that there is not one single use case or usage model that will fit the needs of every developer. Development for Intel(R) Atom(TM) processor based devices tends to have one aspect in common however. In most cases you will want to take advantage of the performance and the high screen resolution of your regular development environment and deploy your build to the real hardware for validation and analysis only. In short, most commonly the usage model will be one of cross development.
The Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) processor addresses this in multiple ways.

The Intel(R) C++ Compiler and the Intel(R) Integrated Performance Primitives will by default be installed on the development host system. To provide a protected build environment without host system library pollution it is however also supported to install these components into the Moblin* Image Creator 2 jailroot system or to install them into a Moblin* 2 developer image running inside a KVM* virtual machine or even on a real target. For the installation into Moblin* Image Creator 2 or into a KVM* image it is recommended to do this following the yum rpm repository based installation process outlined in the Moblin* Integration Guide Moblin_Integration.htm.

Moblin* Image Creator 2 kickstart scripts can be found at
http://software.intel.com/en-us/articles/moblin-integration-software-development-tool-suite-atom/
A template rpm repository definition file for the direct KVM* image installation of compiler and Intel(R) IPP can be found at http://software.intel.com/en-us/articles/installing-compiler-into-kvm-atom/.

The Intel(R) Application Debugger will with the standard installation package be installed on your development host. Via TCP/IP you can connect to and debug a process either running on actual Intel(R) Atom(TM) processor based target hardware or a KVM* virtual machine or some other virtualization method that assures you that the application to be debugged runs in a software environment identical to the later application deployment. Please also have a look at the Getting Started Guide Getting_Started.html that is part of the tool suite distribution for further details on the Intel(R) Application Debugger usage.

The Intel(R) VTune(TM) Performance Analyzer analyzes event based and time based sampling data on the development host. The data has been gathered on an Intel(R) Atom(TM) processor based target platform with low overhead giving you accurate sampling data. The analysis can be done within the standard KDE* or Gnome* based standard Linux* GUI you are used to for your development efforts.

How to develop, and optimize applications for Windows* running on Intel® Atom™ processors
When developing for a Microsoft Windows* XP or Windows* 7 based netbook whose platform is based on the Intel® Atom™ processor, the software development methodology is basically identical to what you are familiar with for writing an application that targets regular notebook PCs.

The whole range of Intel’s software development products are at your disposal.
o Intel® Parallel Studio
A plug-in into Microsoft* Visual Studio* to analyze, and develop multithreaded applications for netbooks, and other Windows/Intel Atom processor based systems
o Intel® C++ Compiler for Windows*
A build solutionto generate highly optimized application code
o Intel® Integrated Performance Primitives Library for Windows*
A highly optimized multimedia library – already including multi-threading / autoscaling
o Intel® Threading Building Blocks
A template library to implement multithreading through C++ templates

For more information on these tools please check on our website for more details on download, evaluation, usage and purchase: http://www.intel.com/software/products.

Additional details on Intel® Atom™ specific development under Windows can be found at

o Developing for Intel® Atom™ Processor running Linux* and Microsoft Windows* XP
http://software.intel.com/en-us/articles/development-atom-linux-and-windows/
o Optimized for the Intel® Atom™ Processor with Intel's Compiler
http://software.intel.com/en-us/articles/atom-optimized-compiler
o Using VTune™ Peformance Analyzer for Intel® Atom™ Processor on Windows* XP
http://software.intel.com/en-us/articles/using-vtune-atom-windows

Usage Details & Examples
The Intel Software network offers a wide range of further reading and whitepapers detailing the different use cases for the Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor and it’s components.

Application Debugging in Cross-Debug Environment
http://software.intel.com/en-us/articles/cross-application-debugging/
Using the VTune(TM) Performance Analyzer Sampling Collector for Mobile Internet Devices
http://software.intel.com/en-us/articles/sampling-collector-mid/
Optimized for the Intel(R) Atom(TM) Processor with Intel's Compiler
http://software.intel.com/en-us/articles/atom-optimized-compiler/
Integrating Intel(R) Software Development Tool Suite Components with Moblin* Image Creator
http://software.intel.com/en-us/articles/moblin-integration-software-development-tool-suite-atom/
Installing the Intel(R) C++ Compiler and Intel(R) Integrated Performance Primitives into KVM* for Intel(R) Atom(TM) Processor targeted development
http://software.intel.com/en-us/articles/installing-compiler-into-kvm-atom/
Compile moblin2 kernel sources with Intel Compiler
http://software.intel.com/en-us/articles/compiler-moblin2-kernel-sources-with-intel-compiler/
Device Driver Debugging on Intel(R) Atom(TM) processor based devices http://software.intel.com/sites/products/documentation/hpc/atom/application/device_driver_debugging.pdf
Building Clutter* GUI libraries using the Intel(R) C++ Compiler
http://software.intel.com/en-us/articles/building-the-moblin-clutter-library-with-the-intel-compiler/
Building FFMEG using the Intel(R) C++ Compiler
http://software.intel.com/en-us/articles/how-to-build-ffmpeg-to-run-under-moblin-2/

References
Product Page: http://www.intel.com/software/products/atomtools
Documentation: http://software.intel.com/en-us/articles/intel-application-tool-suite-documentation/
http://software.intel.com/en-us/articles/intel-embedded-tool-suite-documentation/
Knowledge Base: http://software.intel.com/en-us/articles/software-development-toolsuite-atom-kb/all/1/
Forum: http://software.intel.com/en-us/forums/software-development-toolsuite-atom/

Conclusions
The Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor provide a comprehensive development tools solution for Moblin compliant and Intel(R) Atom(TM) processor based platforms that is versatile and highly configurable in its usage model, tightly integrates with the Moblin SDK and brings the power of Intel’s software development tools solutions to the new class of devices and applications targeted by the Intel(R) Atom(TM) processor.

The application ‘ffmpeg’ consist of three executables and 5 libraries. All the sources can be downloaded using the following svn command:

Ø      svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg

 Required patch

One version which I tried ( download: svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg –r 17944)

has a known problem with the sources. If you try to build the code, then you will get a compile time error:

 libswscale/swscale.c:488: error: ‘PIX_FMT_YUV420PLE’ undeclared

The solution is solved by copying the contents of the libswscale directory from .   http://www.ffmpeg.org/releases/ffmpeg-0.5.tar.bz2    (see http://www.ffmpeg.org/download.html)

Please Note, only the libswscale directory should be copied over the top of the existing files.

Build Instructions

Following instructions will help you build ffmpeg under a Linux system assuming that the tar ball from the download is copied to <install_directory>:

 Ø      cd  <install_directory>

 Ø      cd tar xvfz  ffmpeg.tar.gz   #Extract the tar ball to your local directory. You will find a directory tree under the name ffmpeg installed. All the required sources are installed within this tree provided that you are not enabling any additional third party libraries.

 Ø      cd ffmpeg

 Ø      ./configure –help <cr> # to show all the options available to rebuild ffmpeg. For a reference build with gcc there is no need to provide any parameters to configure. However if you would like to enable any third party libraries like ‘libfaad’, ‘libx264’ etc. then you need to add --enable-libfaad --enable-libx264 etc. as parameters to configure. If this is required make sure that you have these sources available on your development environment and that the third party libraries are rebuilt with the selected compiler / compiler options.

 Ø      ./configure <parameters as below>

 Ø      make <cr> #recommended sequence is ‘make clean’ followed by ‘make’. The rebuild will take several minutes (depending on your development environment). Two versions of each executable are produced: ex. ‘ffmpeg’ and ‘ffmpeg_g’. The ‘*_g’ contains the executable with debug information while the ‘*’ is the stripped version. In addition ‘ffplay, ffplay_g, ffserver and ffserver_g’ are produced as executables and libavutil, libavcodec, libavformat, libavdevice and libswscale are rebuilt.

 Icc build:

Depending on what version of icc you are using different configure parameters may be necessary.

 Using icc v10.1.xxx:

 Ø      ./configure cc=icc --extra-cflags=”-xL –O3” --extra-libs=-lsvml <cr> # Without linking in the extra library (libsvml.so) you get several references unresolved.

 Using icc v11.0.xxx:

 Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” –extra-libs=-lsvml <cr> #  The option –xSSE3_ATOM do require that you run the code on a processor which does support the ‘movbe’ instruction. If you would like to test the code on a processor not supporting the ‘movbe’ instruction you can add the option ‘-minstruction=nomovbe’ in the extra-cflag part of the command line above.
Ø      Make sure that the LD (linker) options do not contain ‘–march=generic’ in the config.mak file. This option causes an error from the compiler.

Using icc v11.1.xxx:

Ø      To avoid a run time erratum following source change is needed:   Open file ./libavcodec/x86/dsputil_mmx.c and on line #2944 insert // before || __ICC > 1100. The line is highlighted below.

Ø      After the change it will look like: #if ARCH_X86_64 || ! ( __ICC) // || __ICC > 1100

Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” <cr> # This simple configure does work but you get better performance if you also add the ‘--extra-lib=-lsvml’. Additional compiler switches can be used to improve the performance – for example ‘-no-prec-div’, ‘-vec-‘. As the no-prec-div has an effect on the fp calculations please refer to the compiler documentation before it is used. In addition the ‘-xSSE3_ATOM’ switch are no longer requiring a processor with ‘movbe’ support.

 Cross compilation.

It is standard practice to build the library and executables on a development machine and then copy the resultant files to the MOBLIN target.  You can use the option --enable–cross-compile in this case.

Once you have completed the configure stage you can just run the ‘make clean’ followed by ‘make’. You could expect additional warnings produced.

Building ffmpeg with third party libraries:

The application can support 21 different external 3^rd party libraries. Each of those are selected in the configure process by adding the option ‘--enable-<library-name>’.

Below is an example of using some of the different external libraries available:

 Ø      ./configure <other options as above> --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid 

The invocation above assumes that you will be using 6 external 3^rd party libraries:

 - libfaac       # for example you can download ‘faac-1.28.tar.gz’ or later version from the web.

 - libfaad       # for example you can download ‘faad2-2.7.tar.gz’ or later version from the web.

 - libmp3lame # for example you can download ‘lame-398-2.tar.gz’ or later version from the web.

 - libtheora    # for example you can download ‘libtheora-1.0.tar.tar’ or later version from the web. Please note that you can not use ICC v 10.1 to rebuild this library due to a compiler issue. This has been fixed with 11.1 version of the compiler.

 - libx264      # for example you can download ‘x264-snapshot-20090117-2245.tar.bz2’ or later version from the web.

 - libxvid      # for example you can download ‘xvidcore-1.2.1.tar.gz’ or later version from the web.

Introduction

Build environment

The build instructions below are based on the assumption that the build environment is a Fedora10 installation. 

A copy of the installation disks can be found here. http://fedoraproject.org/get-fedora

It is important that the GCC tools are installed when the Fedora installation is installed.

Cross-development

The clutter libraries  and test environment  are first built on a Fedora installation, and then the resultant executables and libraries can then be copied over to a MOBLIN2 platform.

Virtualisation

The steps below can be undertaken on a virtual machine, the only restriction being that not all virtual machines support video acceleration  

The tests

There are a number of tests that can be used to benchmark the clutter library. The benchmark performance is measured by how many Frames Per Second (FPS) are achieved.

Building the Clutter Libraries

Downloading the sources

The sources for the clutter library can be obtained by using the following command.

In a development directory of your choosing download the sources

   git clone git://git.clutter-project.org/clutter

   git clone git://git.clutter-project.org/clutter-box2d

Progress for each download should be reported similar the following:

$ git clone git://git.clutter-project.org/clutter

Initialized empty Git repository in /home/intel/dv/clutter/clutter/.git/
remote: Counting objects: 25225, done.
remote: Compressing objects: 100% (10261/10261), done.
remote: Total 25225 (delta 20575), reused 18319 (delta 14944)
Receiving objects: 100% (25225/25225), 6.99 MiB | 104 KiB/s, done.
Resolving deltas: 100% (20575/20575), done.

Building the Sources

Directory structure should look similar to this:

             <dev-dir>/clutter/
            <dev-dir>/clutter-box2d

In each of these sub directories build the libraries as follows:

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=/opt/custom/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc

   export PREFIX=/opt/custom/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

  
                                  Clutter    0.9.7
                         ====================
                                  prefix:   /opt/custom/gcc
                                Flavour:   glx/gl
                                 XInput:   no
                          GL headers:   GL/gl.h
                    Image backend:   gdk-pixbuf
                       Target library:   libclutter-glx-0.9.la
               Clutter debug level:   yes
                 COGL debug level:   minimum
                      Compiler flags:   -Wall -Wshadow -Wcast-align -Wno-uninitialized -Wno-strict-aliasing -Wempty-body -Wformat-security -Winit-self
        Build API documentation:   no
  Build manual documentation:   no
         Build introspection data:   auto

Now build the source by calling make

The progress of the make will be reported, the last few lines looking similar to this:

   Making all in tools
     CC    disable-npots.o
     LINK  libdisable-npots-static.la
     LINK  libdisable-npots.la
   Making all in po

Installing the new library

To install the new library call:

make install

Note, depending on the permissions of the installation directory (set with the $PREFIX variable in the previous steps) you may need to do this as root.

Building the tests

The test directory has a number of tests. The README describes the tests as follows 

"The conform/ tests should be non-interactive unit-tests that verify a single feature is behaving as documented. See conform/ADDING_NEW_TESTS for more details.

 The micro-bench/ tests should be focused performance test, ideally testing a single metric. Please never forget that these tests are synthetic and if you are using them then you understand what metric is being tested. They probably don't reflect any real world application loads and the intention is that you use these tests once you have already determined the crux of your problem and need focused feedback that your changes are indeed improving matters. There is no exit status requirements for these tests, but they should give clear feedback as to their performance. If the frame rate is the feedback metric, then the test should forcibly enable FPS debugging.

 The interactive/ tests are any tests who's  status can not be determined without a user looking at some visual output, or providing some manual input etc. This covers most of the original Clutter tests. Ideally some of these tests will be migrated into the conformance/ directory so they can be used in automated nightly tests."

To build the tests, from the top level of the test directory do: 

    make

The build will report:

    Making all in data
    Making all in conform
    Making all in interactive
    Making all in micro-bench
    Making all in tools

Running the tests

Having built the tests, each test can be run from the command line.

Automatic running of  tests.

Many of the tests do not run to completion, but keep running,  The script in the appendix below gives an example of how the tests can be automatically called and killed after a predefined time.

Appendix 1 -  Script to drive test cases

#!/usr/bin/perl
# list of tests TODO: EDIT THESE TO YOUR REQUIREMENTS
@Tests=("test-actors", "test-behave", "test-clip","test-cogl-offscreen","test-cogl-primitives","test-cogl-tex-convert","test-cogl-tex-foreign","test-cogl-tex-getset","test-cogl-tex-polygontest","test-cogl-tex-tile","test-depth","test-layout","test-multistage","test-pixmap","test-project","test-random-text","test-rotate","test-scale","test-script","test-sharder","test-text","test-texture-quality","test-textures","test-threads","test-unproject","test-viewport");

#@Tests=("test-actors", "test-behave");
@Results=();

# for each test run it for 10 seconds
my $Timeout = 10;
## chdir interactive;
my $bStarted = 0;

foreach my $Test (@Tests)
{
    # print "executing $Test\n ";
    eval {
        local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
        alarm $Timeout;
        # system("./$Test --clutter-show-fps > res.$Test.txt");

        # mark end of prev test
        push @Results, "END" if $bStarted;
        push @Results, "TEST:$Test\n-----------------------\n";
        $bStarted = 1;
        open (RUN,"./$Test --clutter-show-fps &|");
        while(<RUN>)
        {
            push @Results, $_;
        }
        alarm 0;
    };
    if ($@)
    {
        die unless $@ eq "alarm\n"; # propagate unexpected errors
        # timed out
        system("killall -9 lt-test-interactive");
     }
}
# mark the end of the last test
push @Results, "END" if $bStarted;

# process the results
my $NumTests = 0;
my $Total = 0;
my $Max = 0;
my $Min = 9999;
my $TestName="";

print "\nName Min Max NumTests Average\n";
foreach my $Line (@Results)
{
    if($Line=~/^TEST:(.*)/)
    {
        # print "IN TEST $Line";
        $TestName= $1;
        chomp $TestName;
        $NumTests = 0;
        $Total = 0;
        $Max = 0;
        $Min = 9999;
    }

    if($Line=~/END/)
    {
        # print "IN END :$Line";
        $Average = 0;
        $Average = $Total/$NumTests if $NumTests > 0;
        print "$TestName $Min $Max $NumTests $Average\n";
    }

    if($Line=~/\*\*\* FPS: (.*) \*\*\*/)
    {
        # print "IN FPS: $Line";
        $NumTests++;
        $Total = $Total + $1;
        $Max = $1 if $1 > $Max;
        $Min = $1 if $1 < $Min;
    }
}

print "exiting ..\n";
 

 Appendix 2 - Essential notes on installing Fedora  

When installing Fedora you must install the Software Development tools.

Gypsy

Gypsy has replaced gpsd as the GPS daemon for reporting location coordinates in Moblin 2.0. There are many reasons [1] as to why Gypsy may be considered an improvement over gpsd. This article will briefly describe what you can do, as a developer, with Gypsy. A complete API[2] and tutorial [3] are available at http://gypsy.freedesktop.org.

What can Gypsy do?

Gypsy is a convenient way for getting location information from a GPS device. Multiple client applications can connect to Gypsy, and Gypsy can connect to one or more GPS devices [4]. Gypsy can interact with both Bluetooth and Serial (direct connection) devices, and will parse the device's cryptic data [5] into clearer, programmer friendly values [6].

Developers interface directly with Gypsy by using its GLib API. Gypsy also has an open D-Bus API which can be controlled via Linux IPC (interprocess communication). This means that a location based application can be written in any language that supports [7] D-Bus communication, and can appropriately receive information from Gypsy.

How Gypsy data is organized

One difference between Gypsy and gpsd is in how Gypsy organizes its information, using Glib Objects to encapsulate different types of data [8]:

GypsyPosition: holds position data (latitude, longitude, altitude)

GypsyCourse: reports velocity information, in the form of speed, direction, and climb

GypsyAccuracy: reports the estimated accuracy, also known as the Dilution of Precision (DOP) for position in the horizontal and vertical planes

GypsySatellite: contains data from each visible satellite, including the satellite ID # (PRN), elevation, azimuth, and signal-to-noise ratio (SNR)

Each Object uses a method / signal architecture. For example, GypsyPosition has a method gypsy_position_get_position(...) that you can call at anytime to receive the current position. The other approach would be to use GypsyPosition's “position-changed” signal. You can register your own callback method, and instead of continually polling Gypsy for updates, your application will be signaled anytime the position changes.

Manually Locating and Launching Gypsy

The default installation path for gypsy-daemon is /usr/libexec/gypsy-daemon. If you're using the GLib API, you'll need to make sure that the gypsy daemon is running before you try and use it. An added benefit of using the D-Bus API is that gypsy-daemon will automatically launch (if it isn't running already) the first time you make a call to it.

For debugging purposes, it might be useful to execute gypsy-daemon with a “--no-daemon” flag. This will keep the process inside the terminal and spit out debugging information.

Geoclue

Geoclue is a location service that is also included with Moblin 2.0. It uses multiple providers (like Gypsy, gpsd, Hostip, Geonames, etc...) to provide more than the Position/Velocity information given by Gypsy. It can also give Address information based upon your current location. Please see http://www.freedesktop.org/wiki/Software/GeoClue to find out more about Geoclue. If you liked this article, you might also read the author's article on Geoclue.

Building a new ecosystem

In a world where devices are becoming increasingly more mobile, location information is becoming a more integral part of a user's experience. Applications with location features are making it to a variety of different platforms, and are setting a new standard for mobile functionality. Look for Gypsy and Geoclue to carry this standard to Moblin 2.0-based netbooks, MIDs and smartphones.

Whether you intend to do most of your development on a live Moblin* image running inside a KVM* virtual machine ore whether you intend to do your development in a protected jailroot/chroot environment, there are tools components that should be installed on your development host system and should be independent of your Moblin* based Intel(R) Atom(TM) Processor target.

It is recommended to register for the Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) Processor or the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) Processor at http://software.intel.com/en-us/intel-compilers/ and download it at https://registrationcenter.intel.com. It is also recommended to install at least the Intel(R) VTune(TM) Performance Analyzer and the Intel(R) Debugger following the steps outlined in the product installation guide Install_All.htm. This will take care of installing the host components to take advantage of the Intel(R) Application Software Development Tool Suite's performance analysis, tuning and debug capabilities.

To install the Intel(R) C++ Compiler and the Intel(R) Integrated Performance Primitives into the Moblin* Image Creator jailroot environment and prepare the Moblin* Image Creator produced target image to also include the Intel(R) Application Debugger debug agent (Idbserver) and the Intel(R) VTune(TM) Analyzer Sampling Collector (SEP) please follow the steps below:

1. Go to http://www.moblin.org and download Moblin* Image Creator 2. Detailed Moblin* Image Creator documentation can be found at http://moblin.org/documentation/moblin-image-creator-2/using-moblin-image-creator and the Moblin* Image Creator itself can be downloaded at  http://git.moblin.org/cgit.cgi/moblin-image-creator-2 .
2. Follow the instructions you find at moblin.org for installing the Moblin* Image Creator.
3. Go to http://software.intel.com/en-us/articles/moblin-integration-software-development-tool-suite-atom/ and download the two scripts netbook-core-developer_JAILROOT.ks and netbook-core-developer_TARGET.ks .
4. To create a KVM* image or a Live-CD of the target Moblin* system, please use netbook-core-developer_TARGET.ks:
    

   > moblin-image-creator -c <path_to_ks>/netbook-core-developer_TARGET.ks -f raw --cache=/tmp/mycache

   The image created will contain The Intel(R) Application Debugger Idbserver and the Intel(R) VTune(TM) Analyzer Sampling Collector for target system located as a tarball in the /tmp directory. TheParameter '-f raw' of the moblin-image-creator command instructs the Moblin* Image Creator to create an image which can be loaded into a KVM* virtual machine. For more information on Moblin* Image Creator usage please consult moblin.org.

5. To create an image with the Intel(R) C++ Compiler & the Intel(R) Integrated Performanced Primitives that you can then use to do builds in a protected jailroot/chroot environment before creating the target image please use netbook-core-developer_JAILROOT.ks:
    

   > moblin-image-creator -c <path_to_ks>/netbook-core-developer_JAILROOT.ks -f loop --cache=/tmp/mycache

   The image will contain the Intel(R) C++ Compiler and the Intel(R) IPP at /opt/intel/Compiler. The command parameter '-f loop' of moblin-image-creator tells it to create a loop image. You can mount this image and then chroot into it for your protected builds using the following commands:
     

   > mount -o loop moblin-netbook-core-developer_JAIROOT.img /mnt/loop
    > chroot /mnt/loop su

6. To additionally install the Intel(R) VTune(TM) Analyzer Sampling Collector (SEP) you would download it directly from http://downloads.moblinzone.com/development-tool-suite-2/rpm/vtune91_target.tar.gz and unpack it and install it in the Moblin* environment. Please be advised that using SEP is only supported on real Intel(R) Atom(TM) Processor based hardware and not on OS images running under KVM*. 

    

Advanced

If you would like to modify the kickstart script templates provided with the Moblin* Image Creator yourself, below is a short outline of the changes we apply to the template scripts provided with the Moblin* Image Creator to enable our integration. The example kickstart scripts for the Moblin* Image Creator can be found in the /usr/share/mic2 after you installed it.

To enable integration of the Intel(R) Software Development Tool Suite you would do the following:

1. add a repository entry for the Intel(R) Software Development Tool Suite  to the header of ks file:  
      

   > repo --name=intel-tools --baseurl=http://downloads.moblinzone.com/development-tool-suite-2

2. add packages which you want to install into Moblin image in %packages section of the ks file.
   There are 4 groups of Intel packages which you may want to install:
   

     @Compiler
     @IPP
     @Application Debugger
     @Server agent for Application Debugger

Each of these groups contains a set of rpm files related to the corresponding products.
  

@Compiler contains the Intel(R) C++ Compiler for applications runninng on IA-32
  @IPP containsthe Intel(R) IPP for Intel(R) Atom(TM) Processor
  @Application Debuggers contains the Intel(R) Application Debugger 2.0 for Intel(R) Atom(TM) Processor
  @Server agent for Application Debugger conntains the Intel(R) Debugger Remote Server (idbserver) 

    
Each group of packages contains the information about its dependencies which will be automatically resolved during the installation.

Host Install 

It is recommended to register for the Intel(R) Application Software Development Tool Suite for Intel(R) Atom(TM) Processor or the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) Processor at http://software.intel.com/en-us/intel-compilers/ and download it at https://registrationcenter.intel.com. It is also recommended to install at least the Intel(R) VTune(TM) Performance Analyzer and the Intel(R) Debugger following the steps outlined in the product installation guide Install_All.htm. This will take care of installing the host components to take advantage of the Intel(R) Debugger and Intel(R) VTune(RM) Perfromance Analyzers debuging and performance optimization tuning capabilities.

If you wanted to you could however also do the host component install using the kickstart script approach of Moblin Image Creator 2. This is however not the recommended approach.
To the any kickstart script of your choice you would add  the '%post --nochroot' section shown below for copying of the Intel(R) VTune(TM) Performance Analyzer and the Application Debugger to the host machine and VTune sampling collector for embedded systems (SEP-embedded) to the target image.

%post --nochroot

# Copying vtune_for_targets to the target image (set your proxy here if needed)
echo "Downloading required additional packages..."
export http_proxy=http://proxy.jf.intel.com:911
test -s /tmp/vtune91_target.tar.gz || wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/vtune91_target.tar.gz -O /tmp/vtune91_target.tar.gz
cp /tmp/vtune91_target.tar.gz $INSTALL_ROOT/tmp/vtune91_target.tar.gz

# copying VTune for host to the user's host machine
test -d /tmp/intel-tools || mkdir -p /tmp/intel-tools
test -s /tmp/intel-tools/l_vt_pu_9.1.021.tar.gz || wget http://downloads.moblinzone.com/development-tool-suite-2/l_vt_pu_9.1.021.tar.gz -O /tmp/intel-tools/l_vt_pu_9.1.021.tar.gz

# copying Application Debugger to the user's host machine
test -d /tmp/intel-tools/idb || mkdir -p /tmp/intel-tools/idb
wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/intel-mid_idb20006-2.0.006-001.i486.rpm -O /tmp/intel-tools/idb/intel-mid_idb20006-2.0.006-001.i486.rpm
wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/intel-mid_idb-kernel20006-2.0.006-001.i486.rpm -O /tmp/intel-tools/idb/intel-mid_idb-kernel20006-2.0.006-001.i486.rpm
wget http://downloads.moblinzone.com/development-tool-suite-2/rpm/intel-mid_idb-eclipse20006-2.0.006-001.i486.rpm -O /tmp/intel-tools/idb/intel-mid_idb-eclipse20006-2.0.006-001.i486.rpm

# Installing App Debugger (if needed, please remove the comments)
# TODO: write some lines, so that add installation for non-rpm systems (like Ubuntu 8.10)
#echo "Installing an Application Debugger..."
#type -P rpm &>/dev/null
#if [ $? -eq 0 ]; then
# rpm -U --force --nodeps /tmp/intel-tools/idb/intel-mid_idb20006-2.0.006-001.i486.rpm
# rpm -U --force --nodeps /tmp/intel-tools/idb/intel-mid_idb-kernel20006-2.0.006-001.i486.rpm
# rpm -U --force --nodeps /tmp/intel-tools/idb/intel-mid_idb-eclipse20006-2.0.006-001.i486.rpm
#fi

%end

Geoclue is a geoinformation service that will be included in Moblin 2.0. It uses multiple providers (like Gypsy, gpsd, Hostip, Geonames, etc...) to provide more than the Position/Velocity information given by most location-based APIs. For example, it can also give postal address information based upon your current location. With Geoclue, a GPS device isn't the only way to judge your current position. Providers are included that can estimate your position based on GSM (cell towers) and IP / Mac address.

This article will briefly describe what you can do, as a developer, with Geoclue. A complete API[i] and tutorial[ii] are available at http://www.freedesktop.org/wiki/Software/GeoClue.

•             The Geoclue Master Provider

Selecting a provider to use in Geoclue normally requires some knowledge about the hardware that is being used. You would not be able to use the GPS providers (Gypsy and Gpsd) without a GPS device. Likewise, only a compatible phone can get its position using GSM by communicating with cell towers. You may also need to know something about your environment. Providers using Wi-Fi, GPS satellites, and Cell towers will only work as long as you can get a signal from their respective service. Additionally, there are providers that will only give Position information, and there are others that will only give Address information.

The Master Provider is an attempt to take away all of the complications of choosing the right provider. Just like any other provider, you may query for position and address information. The master will choose the best provider to provide what you are looking for. As the environment changes and a provider's signal goes weak, the master automatically switches to another provider and continues the flow of geoinformation.

The master can be controlled via a D-Bus or C API. As previously noted, a simple example (in C) of how to access the master provider is available at http://www.freedesktop.org/wiki/Software/GeoClue.

•             Selecting your own provider

For more control, you may wish to select your own provider. Below is a table of the standard providers[iii] that are included with Geoclue, along with the services that they provide.

Provider	Services	Description
Hostip	Position, Address	A web service that guesses location based on the current IP address.
Plazes	Position, Address	A web service that gets location based on your current router mac address. Interfaces with a user's Plazes account.
Manual	Address	A user-specified address
Localnet	Address	User-specified address that maps to a router's mac address (home, office).
Gsmloc	Position	Gets cell ID data, and estimates location from a web service based upon that data
Gypsy*	Position, Velocity	A GPS daemon that supports bluetooth and serial GPS devices
GPSd*	Position, Velocity	A GPS daemon that uses TCP sockets
Yahoo	Geocode	A web service that converts an address to a position
Geonames	Geocode, ReverseGeocode	A web service that can convert an address to a position. Conversely, it can also find the nearest address to a given position.

*Gypsy vs. Gpsd: As a note, the user should know that in Moblin 2.0, Gypsy is replacing gpsd as the default GPS daemon. See Gypsy's[iv] site for an article[v] that lists why Gypsy may be considered an improvement over gpsd.

•             How Geoclue data is organized

Geoclue divides its geoinformation into Glib Objects to create a modular separation of different types of data. As viewed in the table above, only certain objects / services are available with each provider.

GeocluePosition: holds position data (latitude, longitude, altitude)

GeoclueAddress: returns a HashTable of address information (divided into "street", "postalcode", "area", "locality", "region", "country", etc...)

GeoclueVelocity: reports velocity information, in the form of speed, direction, and climb

GeoclueGeocode: converts an address to a position (latitude, longitude, altitude)

GeoclueReverseGeocode: converts a position to an address

GeoclueAccuracy: reports the horizontal and vertical accuracy levels. This can be applied to each of the previous services, except for GeoclueVelocity

GeocluePosition, Address, and Velocity each use a method / signal architecture. For example, GeocluePosition has a method geoclue_position_get_position(...) that you can call at anytime to receive the current position. The other approach would be to use GeocluePosition's signal. You can create your own callback method that will  execute anytime a "position-changed" signal occurs. Instead of  continually polling Geoclue for updates, your application will be signaled anytime the position changes.

•             Debugging Geoclue Providers

Each provider has its own daemon that runs when it is asked to. The default location for the Geoclue daemons is in the /usr/libexec directory. Running these daemons in separate terminals can be useful for debugging purposes, if you are having trouble connecting to a provider.

•             Building a new ecosystem

In a world where devices are becoming increasingly more mobile, location information is becoming a  more integral part of a user's experience. Applications with location features are making it to a variety of different platforms, and are setting a new standard for mobile functionality. Look for Geoclue to help carry this standard to Moblin 2.0-based netbooks, MIDs and smartphones.

[i]     C API and D-Bus API

[ii]    Using basic Geoclue Providers tutorial

      Master Provider tutorial

[iii]   Geoclue Providers listed

[iv]   Gypsy - A GPS Daemon

[v]    Why should you use Gypsy over GPSD

Design Choices

Many of the functional parts of this application are foundational to everyday applications, requiring features such as user authentication, configuration storage and retrieval, network communications, and user interaction. It’s important to modularize the design as much as possible to both break the overall project down into manageable pieces and to make it easier to reuse the code.

The application checks each time it runs to see whether any user credential information has been entered. If not, it presents a typical user name/password login dialog box and stores the information in an encrypted local configuration file. A preferences dialog box makes it possible to change the user name and password after initial setup along with other program options.

For the initial release of this program, I assume that there is an active network connection. This is a bit of a stretch for the Compal JAX10* MID I tested on: It did not have an active 3G radio, so there was no “always-on” Internet connection. I was able to simulate having a consistent connection by using Wi-Fi, instead. Later versions might check for connectivity and, if currently disconnected, queue up the message to send the next time a connection to the Internet is available.

Another design consideration for the mobile form factor is deciding what happens when a button is pressed. With this particular application, there is a consequence for choosing single-key action; every time the user presses one of the action buttons, a message is sent to Twitter. If you assume the user won’t inadvertently press a button or do something like put the device in a back pocket with the application running, it shouldn’t be a problem. Alternatives might include adding a confirmation dialog box to each action (“Really send message?”), adding a button or a timer to lock the screen, or exiting the program by default after the message is sent.

Building a UI for the Small Screen

One of nice things about Python* is the abundance of libraries to do just about anything you need to do. The Compal* MID used for this project has a number of useful libraries installed as a part of the base operating system, and I chose to take advantage of them. The GTK+* user interface (UI) library contains a wealth of resources for building everything from a simple dialog box to a complex data-entry form. PyGTK is a wrapper around the GTK+ library and provides access to virtually every routine through standard Python objects.
Building a login dialog using PyGTK consists of creating a simple window with individual text boxes for username and password. You can find a good example and explanation of these techniques on the PyGTK tutorial page. In the following code snippet the pass_input.set_visibility(False) line causes the password to be blanked by a dot symbol:

def login(self):
        dialog = gtk.Dialog('Login', 
                            self.window,
                            flags=gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
                            buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_REJECT,
                                     gtk.STOCK_OK, gtk.RESPONSE_ACCEPT))
        dialog.set_default_response(gtk.RESPONSE_ACCEPT)
        
        userbox = gtk.HBox(False)
        
        user_label = gtk.Label('Username:')
        userbox.pack_start(user_label)
        
        user_input = gtk.Entry()
        user_input.set_activates_default(True)
        userbox.pack_start(user_input)
        
        dialog.vbox.pack_start(userbox)
    
        passbox = gtk.HBox(False)
        
        pass_label = gtk.Label('Password:')
        passbox.pack_start(pass_label)

        pass_input = gtk.Entry()
        pass_input.set_activates_default(True)
        pass_input.set_visibility(False)
        passbox.pack_start(pass_input)
	  dialog.vbox.pack_start(passbox)

A second option with GTK+ is to create a table that fills the screen with a matrix of buttons that essentially takes up all the screen real estate. Although doing so might not be as visually appealing, it does accomplish the task of building a finger-friendly interface in which you can easily “click” the right button. It also provides a few more options for adding descriptive text to the button for the Twitter application. In Python, the matrix would look something like this:

def create_table(self):
        self.table = gtk.Table(3,4,True) # Create a 3 row by 4 column table
        button1 = gtk.Button("Button 1") # Create a button named button1
        self.table.attach(button1,0,1,0,1) # put button 1 in location 0,1
        button2 = gtk.Button("Button 2")
        self.table.attach(button2,1,2,0,1)	
        button3 = gtk.Button("Button 3")
        self.table.attach(button3,1,2,0,1)
.
.
.	
        button12 = gtk.Button("Button 12")
        self.table.attach(button12,1,2,0,1)

The lines with a single period are meant to indicate that the sequence repeats down to the final definition of button12.

Coding Practices

Python is a language that allows you to write code by the brute-force method, as in the lines above, or in a more elegant way using concepts like iteration. If you were to define all 12 buttons in a linear fashion, you would need 26 lines of code. Using the Python for construct, you can accomplish the same task in a mere seven lines of code. That equates to less than one-third of the code for this simple example, but the difference would be substantial for a larger table. Here’s the code in a more “Pythonic” way:

    def create_table(self):
        self.table = gtk.Table(3,4,True)
        for row in range(3):
            for col in range(4):
            	name = 'Twitter %i' % (row*4 + col + 1)
            	button = gtk.Button(name)
            	self.table.attach(button, col, col+1, row, row+1)

Keeping your code manageable is important when scripts start to get large. Python functions are a good way to break down your code into small, manageable pieces. It’s also important to point out that everything in Python is an object. You can see this to some extent in the create_table function through the use of the self construct. The function create_table creates a gtk.Table and returns it as an object—hence, the use of self to refer to the object being created. There is an abundance of resources on the Web if you’re not familiar with object-oriented programming concepts.

Taking advantage of all the built-in language features and functions is another way to keep your source code manageable. Python has a module for reading and writing configuration files named ConfigParser. This module provides all the tools you need to save and read program configuration information. It supports different sections and creates a file of name–value pairs within each section. There are even individual methods to retrieve specific types, such as getboolean, getint, and getfloat.

If you can’t find what you need in the Python standard library, chances are that someone else has already written what you need. A quick Google* search typically returns multiple choices for a specific tool. Python-Twitter is a good example of a helper library to accomplish the heavy lifting of sending messages to the Twitter service. It’s hosted on Google Code* and even comes with several sample applications.

You can test code on the Compal MID in several ways. File transfer over a USB port is drop-dead simple and works well.  Optionally, you could attach a USB keyboard to the Compal MID and use the VI editor directly on the device for your editing and the Python interpreter for testing. This method works okay for small proof-of-concept efforts but gets out of control for anything but small, simple programs. Another, similar approach is to use Virtual Network Computing* (VNC) to remotely view the screen on the device through your workstation.

Another way is to use the emulator approach.  The Moblin* project has a tool called the Moblin Image Creator* (MIC) for building platform-specific images. With MIC you can also use the Xephyr* emulator tool to launch an independent session for testing purposes. This method has the advantage of a rapid build / test cycle to help work the bugs out of your code in short order.

A final way might be to test the initial version of the software on your Linux* desktop.  The advantage is that you don’t need MIC.  The disadvantages are that you may need additional hardware for your desktop (GPS, for example) and that you can’t test MID specific functionality (such as screen characteristics).

Lessons Learned

Don’t get bogged down in the details too early in the process. It’s important to completely flesh out your requirements in the beginning, then make some design decisions based on a clear picture of what you’re trying to accomplish. Get comfortable with your development tools—especially the debugging portion—as you’ll probably use them more than you think.

The easier it is for you to test and debug your code, the quicker you’ll get it running.

Have a convenient way to transfer files to your device that doesn’t require a lot of motion. This could be as simple as keeping an easily accessible USB cable plugged into your workstation. When you get down to squashing bugs, it helps to make the process as smooth and painless as possible, especially if you’re editing all the code on a workstation and have to move it over to the device for testing.

Summary

Building a solid application for the MID platform requires the same set of disciplined steps you would use in any software project. Be sure you don’t skip steps like these:

• Take your time on the design process, and consider alternatives.
• Think through the UI design from a user’s perspective before you start coding.
• Write your code with testing in mind.
• Have a clear set of requirements that you can test.
• Use tools such as source code control, and check in your code frequently.

About Author

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.

[root@CompalMID~]#

To start the SSH daemon you must type:

[root@CompalMID~]# /etc/init.d/sshd start

You should see:

Starting sshd:  								[OK]

• Choose a good IDE that you're comfortable with.
• Use a popular Linux distribution like Ubuntu for the operating system of your development computer.
• Don't skimp on your development hardware, and do get a machine with a recent processor and ample memory.
• Use good software development practices, like gathering requirements and using a source code control tool.