Interfaces utilisateurs pour Linux embarqu

(Embedded IHM)
Pierre Ficheux (pierre.ficheux@openwide.fr)
Dcembre 2004

Rsum
Cet article prsente des solutions d'interfaces homme machine (ou IHM) les plus frquemment
utilises dans un environnement Linux embarqu. Aprs une brve introduction sur les interfaces
graphiques dans les environnements embarqus, l'article traitera des principales couches graphiques
bas-niveaux utilises sur Linux (soit X11 et le frame-buffer). La suite de l'article s'attachera la
prsentation de quelques bibliothques graphiques plus ou moins volues disponibles pour le
dveloppement d'applications sous Linux embarqu (Qt, GTK+, MicroWindows/Nano-X,
LCDproc).

Les IHM et les produits industriels

Traditionnellement, l'IHM n'est pas le sujet de prdilection des dveloppeurs systmes et encore
moins celui des dveloppeurs de solutions industrielles. Ces derniers prfrent utiliser leur nergie
peaufiner de superbes pilotes de priphriques, quitte prsenter au final un produit l'interface
plutt sotrique. Si l'on remonte l'origine du systme UNIX, anctre et inspirateur de notre Linux
favori, il n'existait pas d'interface graphique mise part celle offerte indirectement par la connexion
d'un terminal externe au travers d'une connexion srie (RS-232).
Si l'on considre les quipements industriels en gnral (et donc pas toujours quips de Linux, ni
d'un systme d'exploitation d'ailleurs) ils furent longtemps dpourvus d'interface graphique
intuitive. La raison tait en partie technique, car l'utilisation de processeurs peu puissants (microcontrleurs 8 bits et souvent 4 bits) et d'une faible quantit de mmoire obligeaient les concepteurs
conomiser l'octet et donc fournir l'utilisateur quelques tristes boutons poussoirs, quelques LED
et parfois un afficheur LCD basse rsolution. Elle est aussi historique, il y a une tradition
d'austrit dans l'interface des systmes industriels et un appareil srieux se doit forcment d'tre
incomprhensible l'utilisateur :-)
L'avnement du rseau puis du web a quelque peu chang la donne pour certains quipements
volus (donc communicants). Avec l'apparition du web et des navigateurs internet, l'utilisation
des rseaux de type IP dans certains quipements a permis leur contrle par des protocoles
standards tels que SNMP (pour Simple Network Management Protocol). Le pilotage du systme est
ralis depuis un programme dit Manager SNMP dialoguant par IP et UDP avec les agents SNMP
implants dans les quipements. Le principe est simple et le manager est souvent graphique et
relativement convivial bien que rserv aux initis. Ce type de pilotage est rpandu depuis
longtemps dans les quipements rseaux (routeurs, switch, etc.) .
La gnralisation du rseau et surtout de l'implantation de systmes d'exploitations dans les
quipements (souvent drivs d'UNIX) permet aussi depuis longtemps le pilotage distance ou la
mise jour grce des protocoles classiques comme SSH, SFTP, TELNET, FTP. La aussi nous
sommes loin de la convivialit d'une interface graphique d'un client lourd type Windows ou
MacOS. Bien entendu, le fait d'utiliser une interface graphique n'est pas forcment un gage
1

d'efficacit. En tant que vieil utilisateur de GNU-Emacs, j'utilise toujours les squences de touches
imagines par notre ami Richard M. Stallman et jamais ma souris ne va s'aventurer aux abords des
menus droulants de mon diteur favori. Cependant, le fait est qu'une interface graphique a
l'avantage d'tre utilisable par un plus grand nombre, et que de ce fait l'apprentissage en est rduit et
l'interchangeabilit des oprateurs est bien meilleure.
La gnralisation d'Internet, des intranets et autres super-extranets a conduit l'utilisation du
navigateur comme interface banalis de (presque) tout processus informatique. Grce au navigateur,
d'aucun peu configurer son routeur avec la mme logique que celle qu'il a utilis quelques minutes
avant pour rserver son billet TGV et ce quelle que soit la plate forme client utilise.
Bien entendu, il n'est pas envisageable de TOUT piloter depuis un client distant tout d'abord parce
que le rseau n'est pas toujours disponible sur tous les quipements mais aussi parce que le
navigateur a ses limites, en dpit des extensions diverses et varies disponibles ce jour (Java,
Javascript, etc.). De plus certains quipements comme les terminaux en gnral doivent
naturellement disposer d'une interface graphique locale, ce qui nous ramne directement au sujet de
l'article.

L'interface graphique X11

L'interface graphique X Window System, appele galement X11 (pour X version 11) ou tout
simplement X est le choix naturel des systmes UNIX donc de Linux. La raison est galement
historique car ce fut le premier (et quasiment seul) standard d'interface graphique UNIX multi plateformes, open source de surcrot et ce bien avant Linux puisque les premires versions publiques de
X datent du dbut des annes 80. Cependant, la conception de X comme un systme graphique
rparti fait qu'il est complexe, gourmand en ressources et donc pas forcment adapt une
environnement rduit comme Linux embarqu. Les applications tournent sur une machine en
gnral assez puissante appele hte (ou host). L'affichage graphique s'effectue sur un terminal
banalis appel display, les deux systmes tant connects sur un lien (en gnral un rseau de type
IP) supportant le protocole X. La figure ci-dessous schmatise l'architecture de X.

Figure 1. Architecture de X11

Cette architecture puissante mais complexe a le plus souvent peu d'intrt pour un systme
embarqu car dans ce cas l'hte et le display sont dans la mme machine et X apporte plus de
2

lourdeur que d'avantages. Cependant, bon nombres de bibliothques et composants graphiques

commerciaux pour Linux sont uniquement disponibles pour X ce qui force souvent l'utilisation de
ce systme, malgr ses dfauts.
Le paquetage XFree86

Dans le cas de Linux, l'environnement X correspond aux paquetages XFree86 disponibles sur
http://www.xfree86.org mais galement fournis dans la plupart des distributions. En plus de
problmes de lourdeur d'excution, l'empreinte mmoire des paquetages XFree86 est totalement
incompatible avec la plupart des architectures rduites (environ 100 Mo). Traditionnellement la
distribution Xfree86 est installe sur le rpertoire /usr/X11R6.
$ cd /usr/X11R6/
$ du -s *
10176
bin
5772
include
5236
LessTif
84832
lib
10364
man
488
share
$ du -s .
116872 .

Cependant, comme nous pouvons le faire pour le systme Linux (noyau, bibliothques standards,
programmes, etc.) il est toujours possible de rduire la distribution XFree86 afin de satisfaire des
contraintes d'encombrement plus raisonnables. Si nous dtaillons un peu la structure de XFree86, il
apparat que le systme est compos des lments suivants:

le serveur X (soit bin/X)

les clients X (galement situs sur le rpertoire bin)

les bibliothques X (sur lib)

les polices de caractres (sur lib/X11/fonts)

divers autres fichiers de configuration dont le fichier principal de configuration du serveur (soit
/etc/X11/XF86Config)

La rduction de XFree86

Le serveur X est quant lui indispensable mais on peut rduire son empreinte mmoire en
appliquant une mthode similaire l'optimisation du noyau Linux, soit conserver uniquement les
pilotes graphiques adapts au matriel et les extensions indispensables notre application (dans
une installation Linux classique, plusieurs pilotes peuvent tre installs par dfaut). Si nous
comparons une version complte une version rduite, nous pouvons constater que le rapport est
d'environ 20.
$ du -s
1156
$ du -s
21004

/usr/X11R6.gen/lib/modules
/usr/X11R6.gen/lib/modules
/usr/X11R6.orig/lib/modules
/usr/X11R6.orig/lib/modules

Une forte rduction de la taille du serveur X peut tre obtenue en utilisant la carte graphique en
mode VESA (pour Video Electronics Standards Association, voir http://www.vesa.org). Le
3

consortium VESA a publi un standard de BIOS graphique (VBE pour VESA BIOS Extension)
permettant d'utiliser toutes les cartes graphiques compatibles VBE avec un jeu d'instructions
commun. Le serveur XFree86 ncessite des cartes compatibles VBE 2.0 pour fonctionner, ce qui
est le cas de la quasi-totalit des contrleurs graphiques rcents. Bien sr l'utilisation du mode
VESA implique une baisse sensible des performances par rapport au mode acclr spcifique au
contrleur.
Le mode VESA est disponible en installant un minimum de modules pour XFree86.
# pwd
/usr/X11R6/lib/modules
# ls -l
total 756
drwxrwxr-x
2 root
drwxrwxr-x
2 root
drwxrwxr-x
2 root
drwxrwxr-x
2 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
drwxrwxr-x
2 root
-r--r--r-1 root
-r--r--r-1 root

root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root

4096
4096
4096
4096
27286
147402
188930
62372
30942
121454
27262
18494
10210
19786
4096
26253
35007

mai
avr
avr
avr
avr
avr
avr
avr
avr
avr
avr
avr
avr
avr
avr
jun
jun

6
19
19
19
19
19
19
19
19
19
19
19
19
19
19
6
6

12:40
13:08
12:59
11:17
12:58
12:58
12:58
12:58
12:58
12:58
12:58
12:58
12:58
12:58
11:46
2001
2001

drivers
extensions
fonts
input
libddc.a
libfb.a
libint10.a
libpcidata.a
libramdac.a
libscanpci.a
libshadow.a
libshadowfb.a
libvbe.a
libvgahw.a
linux
v10002d.uc
v20002d.uc

La partie driver elle-mme tant rduite la liste qui suit:

# ls -l drivers/
total 40
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root

root
root

21134 jun
14809 jun

6
6

2001 vesa_drv.o
2001 vga_drv.o

De mme, concernant le fichier XF86Config, on slectionnera le pilote en configurant la section

Devices comme suit:
Section "Device"
Identifier "MyVidCard"
Driver
"vesa"
VideoRam
2048
# Insert Clocks lines here if appropriate
EndSection

Afin de complter l'optimisation, il sera galement ncessaire de rduire au strict minimum, voire
au nant, la liste des clients X installs sur la cible. Une autre optimisation importante est la
rduction du nombre de polices de caractres (ou fonts) car le systme embarqu n'aura pas
forcment besoin d'utiliser 20 tailles de polices ni d'tre compatible avec les idogrammes chinois,
japonais ou corens pour lesquels les polices de caractres psent plusieurs centaines de Ko. Bien
sr les modifications comme la suppression d'un rpertoire de polices devront tre rpercutes dans
le fichier de configuration du serveur de polices (soit /etc/X11/fs/config) ou directement dans
le fichier de configuration du serveur si xfs n'est pas utilis. Dans le cas d'un systme rduit, ce
4

dernier cas sera probablement le plus frquent et nous pourrons intervenir au niveau du fichier
XF86Config. Dans l'exemple qui suit, nous avons limit la liste des polices la rsolution 75dpi.
FontPath
FontPath
FontPath

"/usr/X11R6/lib/X11/fonts/misc/"
"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
"/usr/X11R6/lib/X11/fonts/75dpi/"

Au niveau d'un rpertoire de polices, chaque fichier .pcf.gz correspond une police de caractre
utilisable. Dans chaque rpertoire on trouve galement le fichier fonts.dir indiquant la liste des
polices du rpertoire et le fichier fonts.alias qui dfinit des alias plus simples aux noms des
polices X, exemple:
fixed

-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1

Il est important de noter que l'alias fixed correspond au nom de la police par dfaut utilise par le
serveur X, si il ne doit rester qu'une police celle-ci devra tre dfinie comme police fixed. De mme,
si l'on supprime des polices, donc des fichiers .pcf.gz dans un rpertoire de polices, il est
ncessaire de reconstruire le fichier fonts.dir avec l'utilitaire mkfontdir.
# mkfontdir .

Pour terminer l'optimisation de XFree86 il conviendra de slectionner soigneusement les

bibliothques X utilises (cot client, donc cot application) en utilisant une mthode base sur
l'utilisation des scripts mklibs.sh ou mklibs.py dj cits dans plusieurs publications de l'auteur.
Au terme de cette optimisation, on peut esprer rduire la taille de la distribution X en dessous de
10 Mo, ce qui n'est dj pas si mal.
Le serveur XkDrive

Indpendamment de l'empreinte mmoire sur le disque, les versions compltes de X sont

naturellement consommatrices de mmoire vive. Les sources de XFree86 incluent cependant un
serveur trs optimis tant au niveau de l'empreinte mmoire que de la RAM utilise l'excution.
Ce serveur Xkdrive implique quelques limitations, comme l'absence de support des polices
vectorielle et le nombre limit de contrleurs graphiques supports. Il fonctionne cependant trs
bien en mode VESA ou bien en utilisant le frame-buffer Linux qui sera dcrit plus loin dans
l'article. Le rsultat se prsente comme un excutable autonome qui sera parfois mieux adapt une
architecture rduite.
Le fichier excutable serveur Xkdrive n'est pas disponible directement dans les distributions Linux
et il sera ncessaire de le compiler partir des sources de Xfree86. Pour ce faire, il faudra rcuprer
les sources par le site http://www.xfree86.org puis crer un fichier host.def dans le rpertoire
xc/config/cf. Ce fichier aura l'allure suivante:
#define
#define
#define
#define
#define
#define

BuildServersOnly YES
KDriveXServer YES
TinyXServer YES
XfbdevServer NO
XvesaServer YES
BuildType1 YES

On lance ensuite la compilation en excutant la commande:

make World

Lorsque la compilation est termine avec succs, on doit obtenir le message suivant:
Full build of Release 6.6 of the X Window System complete.

Le fichier Xvesa doit galement tre prsent.

$ ls -l programs/Xserver/Xvesa
-rwxrwxr-x
1 pierre
pierre

838540 mai

3 14:31 programs/Xserver/Xvesa

On note la taille relativement modeste de cet excutable qui occupe seulement 800 Ko par
rapport aux 2 Mo au du serveur standard (sans compter les modules associs). On peut tester le
serveur en tapant la commande:
# Xvesa -screen 1024x768x16 &

Dans ce cas nous utiliserons une rsolution de 1024 sur 768 pixels en mode 16 bits (soit 65536
couleurs).

Le frame-buffer de Linux
La frame-buffer permet de piloter les modes graphiques en mode haute rsolution directement
depuis le noyau Linux. Notons que ce n'est pas le cas de la majorit des serveurs X qui pilotent les
cartes graphiques en mode utilisateur! Une des applications principales du frame-buffer est la
possibilit d'afficher un logo au dmarrage du noyau (souvent un pingouin) mais nous allons voir
que cette utilisation est quelque peu rductrice.
Configuration du noyau pour le support frame-buffer

Le support du frame-buffer doit tre activ travers la procdure de configuration du noyau Linux.
Pour le noyau 2.4, la configuration s'effectue dans dans le menu Console drivers/Frame-buffer
comme dcrit dans la figure ci-dessous. On notera que le support VESA est bien entendu disponible
ainsi que celui de nombreux contrleurs graphiques. Dans le cas du support VESA, le choix du
mode frame-buffer s'effectue obligatoirement au dmarrage du systme dans un programme de
dmarrage type LILO ou GRUB, ce mode graphique ne pouvant tre modifi ultrieurement sans
un redmarrage du systme. Dans le cas d'un module ddi un contrleur graphique, le passage en
mode frame-buffer prendra effet lors du chargement du module associ via la commande modprobe
et l'on pourra modifier le mode graphique dynamiquement grce l'utilitaire fbset qui permet de
manipuler le point d'entre du frame-buffer soit par dfaut /dev/fb0.

Figure 2. Configuration du frame-buffer pour le noyau 2.4

Pour le noyau 2.6, le configuration s'effectue dans le menu Device Drivers/Graphics Support
comme dcrit dans la figure ci-dessous.

Figure 3. Configuration du frame-buffer pour le noyau 2.6

Lorsque la configuration est sauve, le nouveau noyau est compil par la procdure habituelle soit
en version 2.4 :
# make dep clean bzImage modules

et en version 2.6 :
# make clean bzImage modules

Au niveau du programme de dmarrage, il faut ensuite indiquer la slection d'un mode graphique ou
bien donner la possibilit l'utilisateur de slectionner ce mode en saisissant le code associ lors du
dmarrage. Dans ce cas on placera simplement une ligne dfinissant le mode graphique dans le
fichier /etc/lilo.conf.
image=/boot/bzImage-2.4.27
label=linux
vga = ASK
...

Dans le cas de GRUB, la mme option sera ajoute dans le fichier /etc/grub.conf au niveau des
paramtres du noyau.
kernel /bzImage-2.4.27 vga=ASK ro root=LABEL=/

Si l'on veut slectionner un mode graphique particulier (exemple: 1024x768 en mode 64K
couleurs), il suffit de saisir le code correspondant au dmarrage du systme. Si le mode est utilis en
permanence, on le donnera comme paramtre la directive vga en fonction du tableau dcrit dans la
documentation du noyau dans le fichier Documentation/fb/vesafb.txt.

640x480

800x600

1024x768 1280x1024

256

0x301

0x303

0x305

0x307

32k

0x310

0x313

0x316

0x319

64k

0x311

0x314

0x317

0x31A

16M

0x312

0x315

0x318

0x31B

Tableau 1. Valeurs des codes VESA

En fonction du tableau ci-dessus, le mode 1024x768x64k s'obtiendra en tapant le code 317 au

niveau du dmarrage.
Quelques utilitaires pour le frame-buffer

Une fois le systme dmarr, on peut vrifier le mode graphique en utilisant la commande fbset.
# fbset
mode "1024x768-76"
# D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz
geometry 1024 768 1024 768 16
timings 12714 128 32 16 4 128 4
rgba 5/11,6/5,5/0,0/0
endmode

Par contre une tentative de modification se soldera comme prvu par un chec car nous sommes en
mode VESA.
# fbset -xres 640 -yres 480 -depth 16
Vesafb does not support changing the video mode
ioctl FBIOPUT_VSCREENINFO: Invalid argument

On peut facilement effectuer des copies d'cran du frame-buffer vers un fichier en utilisant les
programmes fbdump ou fbgrab. La commande fbdump gnre du format PPM (pour Portable
PixMap) alors que fbgrab gnre directement du format PNG.
# fbdump > /tmp/mon_fichier.ppm
# fbgrab /tmp/mon_fichier.png

Le programme fbi permet d'afficher dans le frame-buffer des images aux formats JPEG, PPM, GIF,
TIFF, XWD, BMP, PNG et Photo-CD.

Les bibliothques graphiques

Il existe pas mal de bibliothques graphiques (appeles galement toolkits) dans l'environnement
Linux. Un bon nombre d'entre-elles sont avant tout ddies l'interface X11. Cependant, certaines
bibliothques comme Qt ou GTK+ sont galement disponibles pour le frame-buffer Linux. Ces
bibliothques sont relativement complexes et fournissent un grand nombre de composants
graphiques volus (menus, boutons, etc.). De ce fait elles peuvent tre sur-dimensionnes pour des
environnements rduits ne ncessitant pas une grande complexit graphique ou disposant de
moyens d'affichage rduits. C'est la raison pour laquelle nous prsenterons aussi des bibliothques
beaucoup plus simples (MicroWindows/Nano-X et LCDproc) mais galement beaucoup moins
gourmandes en ressources.
La bibliothque Qt-Embedded

La bilbliothque Qt est dveloppe depuis plusieurs annes par la socit norvgienne Trolltech
(http://www.trolltech.com). Elle est crite en C++ et a l'avantage d'tre multi plate-forme. Le code
source pouvant tre compil pour Linux, Windows ou MacOS. Cette bibliothque a t utilise
entre-autres pour le navigateur OPERA et le bureau KDE. Elle est disponible sous double licence
GPL et propritaire. L'utilisation de la version GPL implique bien sr que le projet associ soit
diffus sous GPL. En cas de diffusion sous licence propritaire, il sera ncessaire de payer une
licence pour Qt. Cependant, ce principe de double licence permet d'valuer totalement le produit
puisqu'il n'y a pas de perte de fonctionnalits entre la version GPL et la version propritaire.
La bibliothque Qt a une excellente rputation de fiabilit mais elle est relativement consommatrice
en ressources (elle est crite en C++). La version GPL de Qt-Embedded est disponible en tlchargement l'adresse http://www.trolltech.com/download/qt/embedded.html. Le plus simple est de
construire le programme de dmonstration qui donne un bon aperu des fonctionnalits de Qt.
La procdure de compilation de la bibliothque est assez simple:
Il faut tout d'abord extraire l'archive tl-charge depuis le site de Trolltech, soit:
$ tar xjvf qt-embedded-free-3.3.3.tar.bz2

Il faut ensuite se placer dans le rpertoire ainsi cr et positionner les variables d'environnements
ncessaires:
$ export QTDIR=`pwd`
$ export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

Il faut ensuite utiliser le script configure pour gnrer l'environnement de compilation de la

bibliothque soit:
$ ./configure -depths 16,24,32

La dernire tape est de compiler la bibliothque, ce qui prend pas mal de temps!
$ make

Lorsque la compilation s'est termine sans erreur, on peut alors excuter le programme de
dmonstration:
# cd examples/launcher
# ./start_demo

10

La fentre affiche a l'allure suivante. Nous pouvons voir que Qt fournit pas mal de composants
graphiques et que ceux-ci sont totalement fonctionnels dans l'environnement frame-buffer.

Figure 4. Dmonstration de Qt-Embedded

La bibliothque GTK+/Embedded
Cette bibliothque a pour origine l'outil d'dition graphique GIMP. A l'poque elle fut cre comme
alternative libre (et plus performante) la bibliothque OSF-Motif qui tait alors propritaire.
Depuis elle a servie de base l'environnement GNOME. Cette bibliothque est crite en C et elle
est diffuse sous licence LGPL, ce qui permet de l'utiliser pour ses propres dveloppements sans
obligatoirement placer son propre code sous GPL. Au niveau des fonctionnalits, elle est
relativement proche de Qt et sera donc rserve aux applications graphiques relativement
complexes.
La compilation de GTK+ est plus complexe que celle de Qt car elle ncessite la prsence de
plusieurs bibliothques annexes pour fonctionner (soit Glib, Pango et ATK). Ces bibliothques sont
disponibles en tl-chargement sur le site de GTK+ (http://www.gtk.org). Pour ce test, nous avons
utilis les versions suivantes des bibliothques:

atk-1.8.0

11

glib-2.4.8

gtk+-2.4.14

pango-1.4.1

Il faut tout d'abord compiler la bibliothque glib en utilisant la procdure classique, soit:
$ ./configure prefix=/usr
$ make
# make install

On peut ensuite faire de mme pour les bibliothques Pango et ATK.

Pour la bibliothque GTK+, il faut indiquer que l'on utiliser le frame-buffer et non la sortie X11 qui
est la configuration par dfaut. Avant cela, il faut appliquer un petit patch la bibliothque car il
semble y avoir un problme de fonction non dfinie si l'on utilise la sortie frame-buffer. La
rfrence du patch tl-charger est disponible dans la bibliographie de l'article. Il est inspir d'un
patch diffus pour GTK+-2.4.0 par Frederic Crozat (fcrozat@mandrakesoft.com) mais il semblerait
que celui-ci n'ait pas t pris en compte par les dveloppeurs de GTK+. La procdure de
compilation est donc la suivante, tout d'abord l'application du patch partir du rpertoire des
sources.
$ patch -p0 <
patching file
patching file
patching file

/tmp/gtk_2.4.4_linux-fb.patch
gdk/linux-fb/gdkdrawable-fb2.c
gdk/linux-fb/gdkfont-fb.c
gdk/linux-fb/gdkwindow-fb.c

Ensuite viennent la gnration de l'environnement via configure en prcisant la sortie framebuffer, puis la compilation et enfin l'installation:
$ ./configure --prefix=/usr --with-gdktarget=linux-fb
$ make
# make install

Lorsque tout est install on peut utiliser le programme de dmonstration prsent dans le rpertoire
demos/gtk-demo des sources de GTK+. Ce programme doit bien entendu tre appel depuis la
console frame-buffer Linux en ayant pris soin de stopper le service gpm (qui gre la souris en mode
texte) si ce dernier tait actif.
# cd demos/gtk-demo
# ./gtk-demo

L'excution du programme de test provoque l'affichage de la fentre suivante:

12

Figure 5. Dmonstration de GTK+/Embedded

On voit donc que GTK+ est assez riche au niveau fonctionnalits mais le support frame-buffer
semble moins bien maintenu.

La bibliothque MicroWindows/Nano-X
Contrairement aux autres bibliothques, MicroWindows et Nano-X ont t dveloppes
spcifiquement pour des applications rduites. Elle sont donc moins riches en fonctionnalits mais
aussi beaucoup moins gourmandes en ressources. Pour donner une ide, un application de
dmonstration MicroWindows occupe environ 300 Ko en version statique ce qui est presque 10 fois
moins qu'un programme Qt ou GTK+ dans les mme conditions. MicroWindows est conu pour
tre proche de l'API de programmation graphique Win32 utilise sous MS Windows. Au contraire,
Nano-X utilise un principe de client/serveur proche de X11.
On peut facilement tester ces bibliothques dans un environnement classique type x86 sous X11 ou
frame-buffer mais elles sont prvues pour la compilation croise vers des processeurs plus ddis
aux environnements embarqus comme l'ARM.
Pour compiler la bibliothque, il faut tout d'abord extraire l'archive tl-charge depuis le site
http://www.microwindows.org. A la date de l'criture de ce document, la dernire version est la
13

0.90.
$ tar xzvf microwindows-0.90.tar.gz

Il faut ensuite se placer dans le rpertoire des sources soit:

$ cd microwindows-0.90/src

MicroWindows n'utilise pas le systme autoconf et la configuration en fonction de la cible doit

s'effectuer la main. Des exemples de fichiers de configuration sont disponibles dans le rpertoire
Configs. Dans notre cas nous pouvons effectuer un test dans l'environnement du frame-buffer
Linux en utilisant le fichier de configuration Configs/config.fb soit:
$ cp Configs/config.fb config

Il reste compiler la bibliothque et les exemples en utilisant la commande:

$ make

Le temps de compilation est beaucoup plus court que pour Qt ou GTK+ ce qui indique bien que
cette bibliothque est beaucoup plus lgre. Pour excuter le programme de test de la bibliothque,
il faut tout d'abord excuter le script mouse.sh qui sous Linux lance simplement le dmon gpm:
# kill old mouse driver
gpm -k
# start mouse driver in repeater mode
gpm -R -t ps2

Il suffit ensuite d'excuter le script demo.sh qui correspond au lancement du programme mdemo:
$ ./demo.sh

Si tout se passe bien, on doit obtenir la fentre suivante:

14

Figure 6. Dmonstration de MicroWindows

La dmonstration de Nano-X s'effectue par le script demo2.sh, qui correspond au lancement de

micro-serveur puis des clients:
$ cat demo2.sh
# Nano-X applications, press <BREAK> key to exit
# bin/nano-X & bin/nanowm & bin/nxview bin/mwlogo.ppm & bin/nxclock & bin/nxmag
& sleep 10000
bin/nano-X & bin/nanowm & bin/nxterm & bin/nxeyes & bin/tux & sleep 10000

b
La fentre affiche a l'allure suivante:

15

Figure 7. Dmonstration de Nano-X

En cas de compilation vers une autre architecture, il suffit de spcifier le nom parmi la liste cite au
dbut du fichier config et bien sr disposer de la chane de compilation croise adquate (exemple:
arm-linux-gcc).
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

build target platform

Valid ARCH values are:
LINUX-NATIVE
LINUX-TCC
LINUX-ARM
LINUX-MIPS
LINUX-POWERPC (BIGENDIAN=Y)
LINUX-SPARC (BIGENDIAN=Y)
LINUX-SH
FREEBSD-X86
SOLARIS (BIGENDIAN=Y)
TRIMEDIA
RTEMS
DJGPP
ELKS
note: ELKS can't build client/server nano-X, nor widget lib

16

#
####################################################################
ARCH
= LINUX-NATIVE
BIGENDIAN
= N
ARMTOOLSPREFIX
= arm-linuxMIPSTOOLSPREFIX
= mipsel-linuxPOWERPCTOOLSPREFIX
= powerpc-linuxSHTOOLSPREFIX
= sh-linux-gnu
RTEMSTOOLSPREFIX
= i386-rtemself-

Pour information, les bibliothque ont t testes avec succs sur un carte d'valuation du
processeur ATMEL AT91RM9200. Cette carte (AT91RM9200-DK) est quipe d'une sortie VGA
pilote par un contrleur EPSON S1D13806 disposant d'un pilote frame-buffer.

Figure 8. Carte AT91RM9200-DK

Une bibliothque d'affichage LCD: LCDproc

Mme si les systmes embarqus deviennent de plus en plus puissants, les applications industrielles
n'ont pas toujours besoin d'un affichage complexe. Bon nombre de systmes se contentent d'un
afficheur cristaux liquides type LCD. Pour ce faire, le projet LCDproc
(http://lcdproc.omnipotent.net) fournit une bibliothque puissante, simple, et utilisable sur plusieurs
afficheurs du commerce. En plus de cela, la bibliothque fournit un pilote de test utilisant l'interface
curses ce qui permet de mettre au point l'application sans disposer d'afficheur rel.
Le principe de LCDproc est bas sur une technique de client/serveur. Le serveur est charg
17

d'effectuer l'affichage sur l'cran LCD et reoit pour cela les requtes des clients travers un socket
TCP sur un le port 13666. Par dfaut le serveur et les clients sont excuts sur une mme machine
(soit localhost) mais rien n'empcherait d'effectuer l'affichage travers Internet.
La compilation de LCDproc ne prsente pas de difficults particulires. Aprs extraction de
l'archive, le mieux est de compiler le paquetage en incluant tous les pilotes d'cran disponibles.
$ ./configure --enable-drivers=all
$ make

Pour tester le systme, il faut tout d'abord slectionner un pilote dans le fichier de configuration du
serveur soit LCDd.conf. Dans notre cas nous utiliserons le pilote de test curses.
[server]
# Server section with all kinds of settings for the LCDd server
#Driver=none
Driver=curses
#Driver=HD44780

Il faut ensuite excuter le programme serveur dans un terminal comme suit. L'option -s indique que
l'affichage des messages d'erreurs utilisera le dmon syslog.
$ ./server/LCDd -c LCDd.conf -s

Le fentre prend alors l'allure suivante.

Figure 9. Dmarrage du serveur LCDproc

On peut alors utiliser le client lcdproc fourni pour effectuer un test d'affichage. Ce client affiche
l'tat du systme en temps rel.
$ ./clients/lcdproc/lcdproc

La fentre d'affichage prend alors l'allure suivante.

18

Figure 10. Serveur LCDproc et client lcdproc

Il est bien entendu possible de piloter directement le serveur depuis un simple client telnet puisque
nous utilisons le protocole TCP. La description des diffrents objets disponibles est prsente dans le
fichier docs/netstuff.txt de la distribution LCDproc.
Dans notre exemple nous effectuons une session telnet dans laquelle:
1. Nous initialisons le protocole LCDproc.
2. Nous crons un cran d'affichage.
3. Nous crons trois objets title, string et scroller auxquels nous affectons des valeurs.
Le texte en gras reprsente les commandes tapes par l'utilisateur, le reste du texte reprsente les
rponses du serveur.
$ telnet localhost 13666
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello
connect LCDproc 0.4.5 protocol 0.3 lcd wid 20 hgt 4 cellwid 5 cellhgt 8
screen_add s
success
listen s
widget_add s t title
success
widget_set s t "Test LCDproc"
success
widget_add s str string
success
widget_set s str 1 4 Texte
success
widget_add s scroll scroller
success
widget_set s scroll 2 3 18 3 h 1 "Une ligne defilante"
success

La fentre du serveur LCDproc prsente alors l'allure suivante.

19

Figure 11. Serveur LCDproc et client telnet

Une bibliothque de gestion d'cran LCD: omm_api

L'origine de cette bibliothque est un projet de lecteur/enregistreur MP3 ralis avec Eric BENARD
il y a quelques annes. Ce projet est dcrit en dtails dans l'ouvrage Linux embarqu cit en
bibliographie. Le but de la bibliothque omm_api est de grer un cran LCD non seulement au
niveau de l'affichage graphique mais aussi des vnements reus, ces vnements correspondant
des codes ASCII. De ce fait, l'application finale est constitue d'un automate pour lequel les
diffrents vnements modifient l'tat.
Le pilotage de l'application se fait au travers de tubes nomms ou bien pour le test via l'entre
standard (stdin). Pour les besoins de cet article nous avons rapidement ralis une adaptation de la
bibliothque afin de s'appuyer galement sur une version trs lgrement modifie de LCDproc, ce
qui n'tait pas le cas auparavant, et cela permet de disposer de tous les afficheurs LCD grs par
LCDproc. La distribution tl-chargeable sur le site de l'auteur (voir bibliographie) fournit deux
exemples:
1. Un programme de dmonstration trs simple: apidemo
2. Un slecteur de fichier: fileselector
Ces programmes sont disponibles pour les environnements matriels suivants:

X11

Curses

Frame-buffer en utilisant la SVGALIB (http://www.svgalib.org), qui est une bibliothque basniveau d'accs au frame-buffer.

LCDproc

Pour compiler la bibliothque et les exemples, il suffit d'extraire l'archive puis d'excuter les
commandes suivantes:
$ make
$ cd fileselector
$ make

Pour tester la dmonstration il suffit de se placer dans le rpertoire des source d'omm_api et de
taper pour la version X11:
20

$ ./apidemox

Les autres versions sont respectivement apidemoc (pour curses) apidemof (pour le frame-buffer)
apidemol (pour LCDproc). La dmonstration affiche un titre centr, une chane de caractres qui
dfile horizontalement ainsi que le caractre envoy par l'utilisateur soit depuis le clavier soit au
travers de la FIFO de communication /tmp/myfifo. Le caractre 'q' provoque la sortie de
l'application. L'excution du programme affiche la fentre suivante.

Figure 12. Dmonstration omm_api

Le slecteur de fichier fileselector suit la mme logique et existe donc en version X11, curses,
frame-buffer et LCDproc. Ce slecteur de fichiers indpendant est pilot partir de codes ASCII
comme dcrit dans le code source fileselector.c.
/* States handling definition */
static omm_event_handler fileselector_event_handlers[] = {
'd', OMM_STATE_INIT, lcd_dump_screen,
/* Dump screen to log file */
'b', OMM_STATE_INIT, lcd_bg_screen,
'r', OMM_STATE_INIT, lcd_fg_screen,
12, OMM_STATE_INIT, filesel_redraw,
/* ^L redraw */
'A'-0x40, OMM_STATE_INIT, filesel_home,
/* ^A home */
'E'-0x40, OMM_STATE_INIT, filesel_end,
/* ^E end */
'U'-0x40, OMM_STATE_INIT, filesel_pgup,
/* ^U PgUp */
'V'-0x40, OMM_STATE_INIT, filesel_pgdown,
/* ^V PgDn */
'j', OMM_STATE_INIT, filesel_down,
/* j Down */
'k', OMM_STATE_INIT, filesel_up,
/* k Up */
'h', OMM_STATE_INIT, filesel_right,
/* r Right */
'l', OMM_STATE_INIT, filesel_left,
/* l Left */
'a', OMM_STATE_INIT, filesel_parent_dir,
/* a Parent directory */
'n', OMM_STATE_INIT, filesel_enter_dir,
/* n Child directory */
'\n', OMM_STATE_INIT, filesel_select,
/* LF Select file(s) */
'\r', OMM_STATE_INIT, filesel_select,
/* CR Select file(s) */
'D', OMM_STATE_INIT, filesel_delete,
/* Remove a file */
't', OMM_STATE_INIT, filesel_mark_file,
/* Mark a file */
'u', OMM_STATE_INIT, filesel_mark_file,
/* Unmark a file */
' ', OMM_STATE_INIT, filesel_toggle_file,
/* toggle-mark file */
'T', OMM_STATE_INIT, filesel_mark_all_files, /* Mark all files */
'U', OMM_STATE_INIT, filesel_unmark_all_files,/* Unmark all files */
27, OMM_STATE_INIT, filesel_quit,
0, 0, NULL
};

Le slecteur permet de naviguer dans une arborescence de fichiers d'un type donn par leur suffixe
et d'effectuer les oprations classiques de parcours des rpertoires, slection simple ou multiple,
effacement, etc. Lorsqu'une liste de fichiers est slectionne, l'action sur la touche Entre provoque
l'affichage de la liste des fichiers slectionns sur stderr. L'arborescence test fournie dans l'archive
21

permet de valider le slecteur. La session suivante indique la recherche de fichiers '.c' (option -S)
dans le rpertoire courant (option -d).
$ cd fileselector/test
$ ../fileselectorx -s -d . -S c

Le slecteur apparat sous la forme suivante.

Figure 13. Slecteur de fichiers

En actionnant la touche 'n' pour entrer dans le rpertoire 'a' puis en slectionnant les deux
fichiers par la barre d'espace on obtient l'cran suivant.

Figure 14. Slection de fichiers

Finalement, en appuyant sur Entre on obtient la liste suivante et l'on quitte le slecteur.
/home/pierre/.../omm_api/fileselector/test/a/y.c
/home/pierre/../omm_api/fileselector/test/a/z.c

D'autres bibliothques graphiques embarques

La liste des projets cite dans cet article n'est bien entendu pas exhaustive et il existe un grand
nombre de projets ddis aux IHM embarques (voir le lien vers la page LinuxDevices.com dans la
bibliographie). On peut cependant citer quelques projets intressants ou prometteurs.
SVGALIB (http://www.svgalib.org)
Cette bibliothque a dj t cite dans le paragraphe prcdent. Elle fournit des fonctions bas
niveau d'accs au frame-buffer (trac de lignes, figures gomtrique, affichage de texte, etc.). Elle
n'est plus trop maintenu ce jour mais elle est simple d'emploi et offre un support VESA
acceptable.
DirectFB (http://www.directfb.org)
22

Beaucoup plus rcente, cette bibliothque fournit un accs au frame-buffer en bas niveau mais avec
des pilotes acclrs.
WxWindows (http://www.wxwindows.org)
Cette bibliothque en C++ permet de programmer des applications graphiques de manire portable
sur plusieurs systmes d'exploitation (Linux, eCOS, Windows, Windows CE, etc.) et ce en
s'appuyant sur diverses couches graphiques (X11, GTK+, MicroWindows, etc.).

Bibliographie

L'ouvrage Linux embarqu paru aux dition Eyrolles en octobre 2002 dont la prsentation est
accessible depuis http://www.ficheux.com.

La
liste
des
principaux
projets
d'interfaces
http://www.linuxdevices.com/articles/AT9202043619.html

Le site du projet Xfree86 sur http://www.xfree86.org

Le site du standard VESA sur http://www.vesa.org

Le
site
de
tl-chargement
de
la
http://www.trolltech.com/download/qt/embedded.html.

Le site du projet GTK+ sur http://www.gtk.org

Le site du projet MicroWindows/Nano-X sur http://www.microwindows.org

Le site du projet LCDproc sur http://lcdproc.omnipotent.net

Le patch appliquer GTK+-2.4.4 afin de compiler la version frame-buffer sur

http://www.ficheux.com/articles/lmf/embedded_ihm/gtk_2.4.4_linux-fb.patch

La bibliothque omm_api sur http://www.ficheux.com/articles/lmf/embedded_ihm/omm_api.tgz

Le patch appliquer LCDproc-0.4.5 pour le test avec omm_api

http://www.ficheux.com/articles/lmf/embedded_ihm/lcdproc-0.4.5_omm_api.patch

23

graphiques

bibliothque

embarques

Qt-Embedded

sur

sur

sur