Learn Qt

Teaching Qt® to the world!


Archive for the ‘Embedded Linux’ Category

Testing Your Embedded Linux Setup – QVFb

First, a quick recap. Last time we created three versions of Qt: Qt/X11, Qt/QVFb and Qt/target. The two first versions are for your development machine, while the later is for building Qt applications for your target platform. If you don’t have a target platform, you can still play along, this entry is only about the virtual framebuffer. Next time, we’ll look at the target version.

The virtual framebuffer.

The virtual framebuffer.

The virtual framebuffer is a tool that you built as a part of the Qt/X11 install. The binary, called qvfb, and is located in the /usr/local/Trolltech/Qt-version/bin directory.

fact-logoAs you have several instances of Qt, where the tools have the same name, you cannot simply add the bin directories to your PATH. Instead, I suggest creating a local bin directory and then create symbol links to each tool. For instance, qvfb-451 could point to the qvfb of your Qt 4.5.1 install. In a similar manner, qmake-version-x11, qmake-version-qvfb and qmake-version-target are handy names for the different qmake instances.

Having started QVFb, you get the boring window shown above. To remedy this, select File Configure…. The dialog (below) lets you setup everything about QVFb – resolution, bit-depth, skins, and more.

Configuring the virtual framebuffer.

Configuring the virtual framebuffer.

By selecting one of the skins (Trolltech-Touchscreen from Qt 4.5.0 in my case – I guess they forgot to change that name to Qt Software) you get a skinned version of the virtual framebuffer. You can move it around by simply dragging and dropping, the buttons work and it looks generally good.

The virtual framebuffer with a skin.

The virtual framebuffer with a skin.

fact-logoNotice that you can alter the settings of QVFb from the command prompt as well. The argument -skin lets you specify a skin while -width, -height and -depth does what they are expected to do.

Another useful aspect of skinning QVFb is that is is a great tool for creating screenshots for your end user documentation. This generally requires custom skins – something that we will look at later on in this series.

Now, all that is left is to run an application. Go to the source tree of your Qt/QVFb and locate examples/widgets/wiggly. To get this running inside the QVFb, first start an instace of the virtual framebuffer and configure it, then run ./wiggly -qws. The argument tells wiggly that it is the Qt Windowing Server, i.e. that it handles the framebuffer device. Without it, it will complain about not being able to connect.

Wiggly running in the virtual framebuffer.

Wiggly running in the virtual framebuffer.

If you can get wiggly running, then you have a proper setup. Now try your own applications. To build your project for QVFb, use the qmake from Qt/QVFb and recompile. To change to Qt/X11, run a make distclean, then the qmake from Qt/X11 and recompile. The distclean part is important, to avoid confusing the build system.

An Embedded Linux Development Setup

When developing applications for an embedded Linux platform, you need to setup a development machine. That machine needs to be running Linux (if you only have Windows boxes, try running a virtual machine). You also need a few key components. There are a few pre-requisites that you need to have in place:

A cross compiler for your target. I.e. a set of tools to build applications for your target environment. If that environment uses the same CPU, glibc and OS as your development machine, this is the same compiler as you are using there. The more likely case is that you will have a specific compiler for your target called something like arm-linux-gcc.

A target with a framebuffer.

fact-logoIf you want to play with embedded Qt without an actual device. You can skip this part and just build the Qt/X11 and Qt/QVFb versions described below.

If you have those two parts, we can start building a Qt environment. First, start by downloading the latest versions of Qt/X11 and Qt for embedded Linux. While that downloads, let’s look into what we are trying to do.

Qt keeps the configuration of the Qt version being used in the qmake utility. The qmake utility is built when Qt is being configured, i.e. before you even compile Qt. We are aiming at building three versions of Qt, so you will have three different instances of qmake. Your job is to keep them apart. We will build the following Qt configurations:

Qt/X11, qmake-x11. This is the Qt version that you will be using on your PC. It is also used for building the tools, such as Designer and Linguist.

Qt/QVFb, qmake-qvfb. This is an embedded Qt configuration that runs on host, but works with the virtual framebuffer instead of the actual screen. The let’s you emulate the target system, but run your code on your host machine.

Qt/target, qmake-target. This is the embedded Qt configuration that runs on your target platform. This is what you use to build and actual application running on your embedded device.

fact-logoTarget or host? The host machine is your development PC, i.e the machine hosting all the source and tools. The target is the device that you are targetting, i.e. the device that is supposed to run your embedded application.

The Qt/X11 build can usually be the Qt installed by default on your distro. I, however, still prefer to build my own Qt. The commands usually goes like ./configure && make -jN, where N is the number of CPUs on your system plus one. When the build is complete (it takes a long time), you need to install it, and you will probably have to do that as root. On ubuntu and derivates, run sudo make install, on non-sudo-distros, run su to become root, then run make install from your root command prompt. The installation will end up in the /usr/local/Trolltech/Qt-<version> directory. You can change this by specifying a prefix when configuring.

You will also have to build the QVFb tool, i.e. the viewer part of the Qt Virtual Framebuffer. We will use this look later, but first, enter the tools/qvfb directory, and run make, then make install (with sudo or su, as when installing all of Qt).

The next step is to build the Qt/QVFb version. This is a variant of embedded Qt, so start by unpacking the embedded Qt source code, then rename the directory to qt-embedded-linux-opensource-src-version to qt-qvfb-version. This is to prevent the other embedded variant that we will build from overwriting this source code.

To build Qt/QVFb, we will need a slightly more complex configure line. The following options is really a minimum, you can add the -help option to configure to learn more.

  • -qt-gfx-qvfb, the graphics driver will be for QVFb, i.e. the virtual framebuffer.
  • -qt-kbd-qvfb, the keyboard input will come from the QVFb.
  • -qt-mouse-qvfb, the mouse input will come from the QVFb.
  • -prefix /usr/local/Trolltech/Qt-qvfb-version, the prefix is used to separate the QVFb version of embedded Qt from the target version.

Having configured the environment, building and installing this version of Qt is no different from the Qt/X11 build (and it takes just as long).

The final version of Qt to build is Qt/target – in my case Qt/arm. This is slightly more complex, as you will have to tell Qt how to cross compile itself for your target. Start by uncompressing the embedded Qt source code again. This time, let’s rename the directory qt-target-version (e.g. qt-arm-version).

Configuring Qt for an embedded target involves two steps (at least). You will need to create a mkspec, helping Qt understanding how to build for your system. Then you need to configure Qt for your target.

So, first things first. The mkspecs for embedded systems are kept in the mkspecs/qws directory. Here, you can usually find a good starting point. For instance, in my case the mkspecs/qws/linux-arm-g++ looks about right. Opening the qmake.conf file, I can verify that the name of the compiler, linker, and all the other tools look right. The default, arm-linux-*, looks right, so I can use this file right away.

The next step is to configure Qt, both to understand the embedded target, to reduce size and to use the right mkspec. I generally start by running ./configure -help, to get an overview of the available options. Below follows a list of the configure options that I recommend using:

First of all, you need to get the cross compilation right:

  • -embedded arm
  • -xplatform qws/linux-arm-g++

Then, we want a release build for target, and we want a prefix:

  • -release
  • -prefix /usr/local/Trolltech/Qt-target-version

You need to know the colour depth of your screen:

  • -depth 16

Finally, there are a number of libraries that you can build into Qt, to avoid having to deploy them separately. If you have no other need for the libraries, I generally compile them as a part of Qt:

  • -qt-zlib
  • -qt-freetype
  • -qt-libjpeg
  • -qt-libng

In a similar manner, some options can be turned off (make sure to go through the entire help message to disable anything that you won’t be using):

  • -no-gif
  • -no-libtiff
  • -no-qt3support
  • -no-glib
  • etc.

Finally, we need to make sure that Qt uses the right keyboard, mouse and screen drivers:

  • -qt-gfx-linuxfb
  • -qt-kbd-tty
  • -qt-mouse-tslib

This will give you a fairly long configuration line. It might be good to know that the file config.status is created when you configure Qt and contains your last attempt. I say last attempt, because this process can take some tweaking.

Now, all you need to do is to make and make install as with the previous Qt versions. This should give you a nicely configured Qt for your target environment. Next time, we will take all the Qt versions you’ve built for a test ride.

You are currently browsing the archives for the Embedded Linux category.