GAL2024 - Méthane 2030 : une démarche collective française à destination de t...
Les technologies Open Source pour les interfaces graphiques embarquées
1. Solutions IHM pour Linux embarqué
Contact :Jérémy ROSEN - 01 42 68 28 04 - jeremy.rosen@openwide.fr
2. NOM
CLIENT
2
Programme
● Présentation d'Open Wide
● IHM et embarqué : spécificités
● Les approches possibles
● Xorg, Wayland et le Framebuffer
● Les bibliothèques graphiques
– DirectFB
– SDL
● Les toolkits
– Qt
– EFL
– GTK
● HMTL5
● Android
3. NOM
CLIENT
3
Présentation Open Wide
● Entreprise créée en septembre 2001
● Environ 120 salariés sur Paris, Lyon et Toulouse
● Industrialisation de composants open source
● Quatre activités :
– OW Système d'Information
– OW Outsourcing: hébergement
– OW Ingénierie: informatique industrielle
– OW Technologies: composants Java
4. NOM
CLIENT
4
IHM et embarqué
● IHM = Interface Home Machine : affichage et saisies
● Ce fut longtemps un problème mineur car peu utilisées dans
l’embarqué
– Système autonome sans affichage (RTOS)
– Configuration par réseau (SNMP, HTTP…)
● Évolution des systèmes, passage du RTOS au multimédia
– Set-top box
– Smartphones
– Industriel → début de l’utilisation d’Android
● L'IHM n'est (était) pas le sujet de prédilection des
spécialistes du logiciel embarqué
5. NOM
CLIENT
5
Particularité des IHM embarquées
● Contraintes classiques de l'embarqué
– Processeur
– RAM
– Carte vidéo, accélération matérielle
● Contraintes sur les périphériques de sortie
– Afficheur LCD
– Écrans de téléphone mobile
– Écrans normaux
● Saisie (et donc ergonomie) spécifique
– Boutons/télécommandes/joystick/main sales
– Touch-screen
– Reconnaissance/saisie vocale
● Environnement de travail
– Compétence des équipes
– Travail déporté/sur émulateur/sans hardware
6. NOM
CLIENT
6
Plusieurs approches
● Développement d'une application embarquée
– Le cas général, proche du desktop Linux
– Équipe applicatif et graphique similaire
– Travail sur émulateur ou sur plateforme
● Sous-traitance de l'applicatif vers une technologie spécifique
– Android/html5
– Framework très connu
– Compétences faciles à trouver
– Développement séparé du produit final
– Ne dispense pas d'une équipe système
– Pas toujours adapté aux spécificités de l'embarqué
– Pas toujours adaptable aux périphériques spécifiques
7. NOM
CLIENT
7
Le framebuffer 1/2
● Pilotage de la carte directement par le noyau (/dev/fb0 → plus
de client/serveur)
● Mode VGA, SVGA, VESA ou (parfois) accéléré
● Programmation très bas-niveau (pixel)
$ cp /dev/fb0 copie_ecran.raw
● Avantages :
– Léger (faible consommation RAM)
– Démarrage rapide
● Inconvénients :
– Pilote spécial → drivers/video
– Peu standard par rapport à X11 sur desktop
8. NOM
CLIENT
8
Le framebuffer 2/2
● Exemples d'utilitaires/bibliothèques disponibles/compatibles
– Bas niveau → fbset, fbi, fbdump, ...
– SVGALIB → DOOM :-)
– DirectFB (abstraction du FB)
– EFL
– SDL
– QtEmbedded
– X11 sur FB
– ...
9. NOM
CLIENT
9
X11, 1/2
● Linux est un UNIX
– Mode texte par défaut
– « X Window System » ou X11 à partir de 84
– Xorg à partir de 2004
● Créé au MIT
● Système graphique réparti, modèle client/serveur →
XFree86 (x86), X.org
● Puissant mais lourd + API complexe (rendering)
● Approche répartie rarement utilisée
Utilisation de X11 →
10. NOM
CLIENT
10
X11, 2/2
● Initialement peu adapté à l’embarqué
● Retour grâce à plusieurs éléments :
– L'augmentation de la puissance des CPU embarqués
– L'utilisation de l'Atom/x86
– Le pilote accéléré devient commun au desktop et à l'embarqué
Qt, GTK
Motif
11. NOM
CLIENT
11
Wayland 1/3
● X11 a atteint ses limites
– Mauvaise intégration au kernel, drivers intégrés à X11
– Protocole réseau inutile
– Protocole au niveau rendering (fonts, inputs, dessin) quasi inutilisé de nos jours
– Pas de compositing, partage de GPU quasi impossible
● Wayland reconstruit sur les besoins modernes
– XOrg a fait passé les drivers dans le noyau (GEM/KMS/DRM)
– Wayland supporte toujours le protocole X via XWayland
● Principalement ce qu'on fait actuellement avec X11, mais
sans couches intermédiaires
12. NOM
CLIENT
12
Wayland 2/3
Protocole de communication client/compositeur
● Le client dessine dans des buffers mémoire
– Demande des buffers au kernel
– Utilise EGL si nécessaire
– Dessine lui même les widget et les décorations (via des librairies)
● Le compositeur place les buffers à l'écran
– Réécrit et redirige les inputs
– Reçoit les demandes de refresh des clients
– Reçoit les handles vers les buffers des clients
● Pas de fonctions desktop avancées
– Drag & Drop, iconify, XDG
– Délégué à des programmes tiers
14. NOM
CLIENT
14
Wayland 3/3
● Déjà présent dans le monde de l'embarqué
– Genivi
– Sailfish OS
● Demande une version adaptée des toolkits pour le client
– Supporté par EFL, Gtk+3.10, Qt5, SDL (expérimental)
● Demande un compositeur
– Weston
– Lipstick (Sailfish OS)
– Gtk, Qt, EFL : en cours d'écriture
Wayland n'est pas encore mature mais ce sera sans doute la solution
par défaut pour l'embarqué dans quelques années
15. NOM
CLIENT
15
Bibliothèques graphiques
● Se placent « au dessus » de X11, Wayland ou du framebuffer
● Deux catégories
– Les bibliothèques d'abstraction → portabilité mais pas d'objets graphiques évolués (SDL,
DirectFB)
– Les toolkits graphiques → fournissent des objets graphiques et peuvent se placer au
dessus des bibliothèques d'abstraction
Qt → X11
Qt → Wayland
Qt → FB
Qt → DirectFB
16. NOM
CLIENT
16
● Bibliothèque d’ « abstraction »
du framebuffer
● Fonctionne avec le
framebuffer Linux mais
également avec X11
(--enable-x11)
● Prise en compte des entrées
(souris, clavier, …)
● Fournit des pilotes FB
accélérés
18. NOM
CLIENT
18
Bibliothèque principalement concue pour le jeu vidéo et les besoins
que cela entraîne.
● Fournit des primitives graphiques ET audio
● Portables sur Linux, Windows, Mac OS X, IOS, Android
● Pour Linux, utilisable sur framebuffer, DirectFB, X11
● Utilisée pour le portage d’applications graphiques (jeux) et
légères
● Gestion basique de l’écran: fenêtres, transparence, polices de
caractères, …
● Supporte OpenGL et Direct3D
● Gestion des Input, du son, du réseau, des threads etc...
21. NOM
CLIENT
21
● Toolkit C++ publié par Trolltech en 1996 (X11)
● Outil multi-plateforme (Linux (X11, Wayland, DirectFB...),
Windows, MacOS, Android, iOS ...)
● Connu grâce à KDE
● Dernière version: 5.3
● Avantages :
– Couvre plus que la partie graphique
– Excellente documentation
– Outil de conception d'interface wysiwyg (QtCreator)
● Inconvénients :
– Lourd (comparé aux autres)
23. NOM
CLIENT
23
EFL
● Toolkit C
● Avantages :
– Peu gourmand en ressources, rapide
– Taillé pour l'embarqué
– Esthétique, modulaire, configurable
● Inconvénients
– Peu connu
– Moins de documentation que pour Qt
– Pas de constructeur d'interface
25. NOM
CLIENT
25
● Développé pour GIMP (Gimp ToolKit)
● Toolkit en C multiplateforme (Linux, Windows, MacOS X)
● Construit sur la Glib (programmation OO en C, énormément de
fonctions de base)
● Assez peu utilisé dans l'embarqué
● Nécessite X11 ou Wayland (pas de FB)
GTK+
26. NOM
CLIENT
26
La prochaine version de la norme HTML permettra de développer des
applications complètement offline et non pas seulement des pages web.
●
Assure une certaine « indépendance » par rapport à la plateforme
●
Maquettage aisé sur desktop
●
IHM déportées
●
Supporté nativement par Android et iOS
●
Nécessite un navigateur web récent sur la plateforme (Gecko/firefox,
Blink/Chrome, Webkit/Tizen+Android)
●
Équipe d'IHM avec compétence web (Javascript)
●
Ne dispense pas de l'ingénieur système
●
Intéressant s'il y a une connexion web
●
Toutes les particularités de l'embarqué ne sont pas gérées
HTML
27. NOM
CLIENT
27
Android
● Android n'est pas une IHM, c'est un OS.
● Difficile à adapter à un HW spécifique, prévu pour des
téléphones.
● Très bien documenté
● Beaucoup de protocoles de communication (NFC, Bluetooth, Wifi,
USB)
● Compétence de développement spécifique.
● La compétence plateforme n'a rien à voir avec la compétence
développement applicatif
Android est surtout intéressant pour des UI déportés (sur le
téléphone de l'utilisateur)
29. Solutions IHM pour Linux embarqué
Contact :Jérémy ROSEN - 01 42 68 28 04 - jeremy.rosen@openwide.fr
30. NOM
CLIENT
2
Programme
● Présentation d'Open Wide
● IHM et embarqué : spécificités
● Les approches possibles
● Xorg, Wayland et le Framebuffer
● Les bibliothèques graphiques
– DirectFB
– SDL
● Les toolkits
– Qt
– EFL
– GTK
● HMTL5
● Android
31. NOM
CLIENT
3
Présentation Open Wide
● Entreprise créée en septembre 2001
● Environ 120 salariés sur Paris, Lyon et Toulouse
● Industrialisation de composants open source
● Quatre activités :
– OW Système d'Information
– OW Outsourcing: hébergement
– OW Ingénierie: informatique industrielle
– OW Technologies: composants Java
32. NOM
CLIENT
4
IHM et embarqué
● IHM = Interface Home Machine : affichage et saisies
● Ce fut longtemps un problème mineur car peu utilisées dans
l’embarqué
– Système autonome sans affichage (RTOS)
– Configuration par réseau (SNMP, HTTP…)
● Évolution des systèmes, passage du RTOS au multimédia
– Set-top box
– Smartphones
– Industriel → début de l’utilisation d’Android
● L'IHM n'est (était) pas le sujet de prédilection des
spécialistes du logiciel embarqué
33. NOM
CLIENT
5
Particularité des IHM embarquées
● Contraintes classiques de l'embarqué
– Processeur
– RAM
– Carte vidéo, accélération matérielle
● Contraintes sur les périphériques de sortie
– Afficheur LCD
– Écrans de téléphone mobile
– Écrans normaux
● Saisie (et donc ergonomie) spécifique
– Boutons/télécommandes/joystick/main sales
– Touch-screen
– Reconnaissance/saisie vocale
● Environnement de travail
– Compétence des équipes
– Travail déporté/sur émulateur/sans hardware
Google glass (voix/écran)
Smartwatch
Android Wear
34. NOM
CLIENT
6
Plusieurs approches
● Développement d'une application embarquée
– Le cas général, proche du desktop Linux
– Équipe applicatif et graphique similaire
– Travail sur émulateur ou sur plateforme
● Sous-traitance de l'applicatif vers une technologie spécifique
– Android/html5
– Framework très connu
– Compétences faciles à trouver
– Développement séparé du produit final
– Ne dispense pas d'une équipe système
– Pas toujours adapté aux spécificités de l'embarqué
– Pas toujours adaptable aux périphériques spécifiques
35. NOM
CLIENT
7
Le framebuffer 1/2
● Pilotage de la carte directement par le noyau (/dev/fb0 → plus
de client/serveur)
● Mode VGA, SVGA, VESA ou (parfois) accéléré
● Programmation très bas-niveau (pixel)
$ cp /dev/fb0 copie_ecran.raw
● Avantages :
– Léger (faible consommation RAM)
– Démarrage rapide
● Inconvénients :
– Pilote spécial → drivers/video
– Peu standard par rapport à X11 sur desktop
36. NOM
CLIENT
8
Le framebuffer 2/2
● Exemples d'utilitaires/bibliothèques disponibles/compatibles
– Bas niveau → fbset, fbi, fbdump, ...
– SVGALIB → DOOM :-)
– DirectFB (abstraction du FB)
– EFL
– SDL
– QtEmbedded
– X11 sur FB
– ...
37. NOM
CLIENT
9
X11, 1/2
● Linux est un UNIX
– Mode texte par défaut
– « X Window System » ou X11 à partir de 84
– Xorg à partir de 2004
● Créé au MIT
● Système graphique réparti, modèle client/serveur →
XFree86 (x86), X.org
● Puissant mais lourd + API complexe (rendering)
● Approche répartie rarement utilisée
Utilisation de X11 →
38. NOM
CLIENT
10
X11, 2/2
● Initialement peu adapté à l’embarqué
● Retour grâce à plusieurs éléments :
– L'augmentation de la puissance des CPU embarqués
– L'utilisation de l'Atom/x86
– Le pilote accéléré devient commun au desktop et à l'embarqué
Qt, GTK
Motif
39. NOM
CLIENT
11
Wayland 1/3
● X11 a atteint ses limites
– Mauvaise intégration au kernel, drivers intégrés à X11
– Protocole réseau inutile
– Protocole au niveau rendering (fonts, inputs, dessin) quasi inutilisé de nos jours
– Pas de compositing, partage de GPU quasi impossible
● Wayland reconstruit sur les besoins modernes
– XOrg a fait passé les drivers dans le noyau (GEM/KMS/DRM)
– Wayland supporte toujours le protocole X via XWayland
● Principalement ce qu'on fait actuellement avec X11, mais
sans couches intermédiaires
Modifier le dernier point.
40. NOM
CLIENT
12
Wayland 2/3
Protocole de communication client/compositeur
● Le client dessine dans des buffers mémoire
– Demande des buffers au kernel
– Utilise EGL si nécessaire
– Dessine lui même les widget et les décorations (via des librairies)
● Le compositeur place les buffers à l'écran
– Réécrit et redirige les inputs
– Reçoit les demandes de refresh des clients
– Reçoit les handles vers les buffers des clients
● Pas de fonctions desktop avancées
– Drag & Drop, iconify, XDG
– Délégué à des programmes tiers
http://wayland.freedesktop.org/archit
ecture.html
42. NOM
CLIENT
14
Wayland 3/3
● Déjà présent dans le monde de l'embarqué
– Genivi
– Sailfish OS
● Demande une version adaptée des toolkits pour le client
– Supporté par EFL, Gtk+3.10, Qt5, SDL (expérimental)
● Demande un compositeur
– Weston
– Lipstick (Sailfish OS)
– Gtk, Qt, EFL : en cours d'écriture
Wayland n'est pas encore mature mais ce sera sans doute la solution
par défaut pour l'embarqué dans quelques années
43. NOM
CLIENT
15
Bibliothèques graphiques
● Se placent « au dessus » de X11, Wayland ou du framebuffer
● Deux catégories
– Les bibliothèques d'abstraction → portabilité mais pas d'objets graphiques évolués (SDL,
DirectFB)
– Les toolkits graphiques → fournissent des objets graphiques et peuvent se placer au
dessus des bibliothèques d'abstraction
Qt → X11
Qt → Wayland
Qt → FB
Qt → DirectFB
44. NOM
CLIENT
16
● Bibliothèque d’ « abstraction »
du framebuffer
● Fonctionne avec le
framebuffer Linux mais
également avec X11
(--enable-x11)
● Prise en compte des entrées
(souris, clavier, …)
● Fournit des pilotes FB
accélérés
Standard avec certains
constructeurs de hardware (sigma)
46. NOM
CLIENT
18
Bibliothèque principalement concue pour le jeu vidéo et les besoins
que cela entraîne.
● Fournit des primitives graphiques ET audio
● Portables sur Linux, Windows, Mac OS X, IOS, Android
● Pour Linux, utilisable sur framebuffer, DirectFB, X11
● Utilisée pour le portage d’applications graphiques (jeux) et
légères
● Gestion basique de l’écran: fenêtres, transparence, polices de
caractères, …
● Supporte OpenGL et Direct3D
● Gestion des Input, du son, du réseau, des threads etc...
49. NOM
CLIENT
21
● Toolkit C++ publié par Trolltech en 1996 (X11)
● Outil multi-plateforme (Linux (X11, Wayland, DirectFB...),
Windows, MacOS, Android, iOS ...)
● Connu grâce à KDE
● Dernière version: 5.3
● Avantages :
– Couvre plus que la partie graphique
– Excellente documentation
– Outil de conception d'interface wysiwyg (QtCreator)
● Inconvénients :
– Lourd (comparé aux autres)
51. NOM
CLIENT
23
EFL
● Toolkit C
● Avantages :
– Peu gourmand en ressources, rapide
– Taillé pour l'embarqué
– Esthétique, modulaire, configurable
● Inconvénients
– Peu connu
– Moins de documentation que pour Qt
– Pas de constructeur d'interface
53. NOM
CLIENT
25
● Développé pour GIMP (Gimp ToolKit)
● Toolkit en C multiplateforme (Linux, Windows, MacOS X)
● Construit sur la Glib (programmation OO en C, énormément de
fonctions de base)
● Assez peu utilisé dans l'embarqué
● Nécessite X11 ou Wayland (pas de FB)
GTK+
54. NOM
CLIENT
26
La prochaine version de la norme HTML permettra de développer des
applications complètement offline et non pas seulement des pages web.
●
Assure une certaine « indépendance » par rapport à la plateforme
●
Maquettage aisé sur desktop
●
IHM déportées
●
Supporté nativement par Android et iOS
●
Nécessite un navigateur web récent sur la plateforme (Gecko/firefox,
Blink/Chrome, Webkit/Tizen+Android)
●
Équipe d'IHM avec compétence web (Javascript)
●
Ne dispense pas de l'ingénieur système
●
Intéressant s'il y a une connexion web
●
Toutes les particularités de l'embarqué ne sont pas gérées
HTML
Eco systeme brouillon
55. NOM
CLIENT
27
Android
● Android n'est pas une IHM, c'est un OS.
● Difficile à adapter à un HW spécifique, prévu pour des
téléphones.
● Très bien documenté
● Beaucoup de protocoles de communication (NFC, Bluetooth, Wifi,
USB)
● Compétence de développement spécifique.
● La compétence plateforme n'a rien à voir avec la compétence
développement applicatif
Android est surtout intéressant pour des UI déportés (sur le
téléphone de l'utilisateur)