IHM embarqué - Open Wide Ingénierie

Solutions IHM pour Linux embarqué
Contact :Jérémy ROSEN - 01 42 68 28 04 - [email protected]
Programme
NOM
CLIENT
●
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
2
Présentation Open Wide
NOM
CLIENT
●
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
3
IHM et embarqué
NOM
CLIENT
●
●
●
●
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é
4
Particularité des IHM embarquées
NOM
●
●
●
●
Contraintes classiques de l'embarqué
–
Processeur
–
RAM
–
Carte vidéo, accélération matérielle
CLIENT
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
5
Plusieurs approches
NOM
CLIENT
●
●
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
6
Le framebufferNOM
1/2
CLIENT
●
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
7
Le framebufferNOM
2/2
CLIENT
●
Exemples d'utilitaires/bibliothèques disponibles/compatibles
–
Bas niveau → fbset, fbi, fbdump, ...
–
SVGALIB → DOOM :-)
–
DirectFB (abstraction du FB)
–
EFL
–
SDL
–
QtEmbedded
–
X11 sur FB
–
...
8
X11,NOM
1/2
CLIENT
●
●
●
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 →
9
X11,NOM
2/2
CLIENT
●
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é
Motif
Qt, GTK
10
WaylandNOM
1/3
CLIENT
●
●
●
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
11
WaylandNOM
2/3
CLIENT
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
12
Wayland Architecture
NOM
CLIENT
●
Architecures comparées X/Wayland
13
WaylandNOM
3/3
CLIENT
●
●
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
14
Bibliothèques graphiques
NOM
CLIENT
●
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
15
NOM
CLIENT
●
●
●
●
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
accélérés
pilotes
FB
16
Exemple DirectFB
NOM
CLIENT
17
NOM
CLIENT
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...
18
Exemple NOM
SDL
CLIENT
19
Les « toolkits » graphiques
NOM
CLIENT
●
●
Fournissent un ensemble d’objets graphiques
–
Menus
–
Boutons
–
Boîtes de dialogues
–
WebView
–
Mediaplayer
Exemples:
–
Athena widgets, OSF-Motif (X11) → obsolète
–
WxWidgets → obsolète
–
Qt
–
EFL (Enlightenment, E18)
–
GTK+
20
NOM
CLIENT
●
●
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)
21
Qt sur Mini2440
NOM
CLIENT
22
EFL
NOM
CLIENT
●
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
23
EFL au NOM
frigo
CLIENT
24
GTK+
NOM
CLIENT
●
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)
25
HTML NOM
CLIENT
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
26
Android
●
●
●
●
●
●
NOM
CLIENT
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)
27
Questions?
Solutions IHM pour Linux embarqué
Contact :Jérémy ROSEN - 01 42 68 28 04 - [email protected]
Programme
NOM
CLIENT
●
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
2
Présentation Open Wide
NOM
CLIENT
●
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
3
IHM et embarqué
NOM
CLIENT
●
●
●
●
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é
4
Particularité des IHM embarquées
NOM
●
●
●
●
Contraintes classiques de l'embarqué
–
Processeur
–
RAM
–
Carte vidéo, accélération matérielle
CLIENT
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
5
Google glass (voix/écran)
Smartwatch
Android Wear
Plusieurs approches
NOM
CLIENT
●
●
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
6
Le framebufferNOM
1/2
CLIENT
●
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
7
Le framebufferNOM
2/2
CLIENT
●
Exemples d'utilitaires/bibliothèques disponibles/compatibles
–
Bas niveau → fbset, fbi, fbdump, ...
–
SVGALIB → DOOM :-)
–
DirectFB (abstraction du FB)
–
EFL
–
SDL
–
QtEmbedded
–
X11 sur FB
–
...
8
X11,NOM
1/2
CLIENT
●
●
●
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 →
9
X11,NOM
2/2
CLIENT
●
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é
Motif
Qt, GTK
10
WaylandNOM
1/3
CLIENT
●
●
●
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
11
Modifier le dernier point.
WaylandNOM
2/3
CLIENT
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
12
http://wayland.freedesktop.org/archit
ecture.html
Wayland Architecture
NOM
CLIENT
●
Architecures comparées X/Wayland
13
WaylandNOM
3/3
CLIENT
●
●
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
14
Bibliothèques graphiques
NOM
CLIENT
●
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
15
NOM
CLIENT
●
●
●
●
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
accélérés
pilotes
FB
16
Standard avec certains
constructeurs de hardware (sigma)
Exemple DirectFB
NOM
CLIENT
17
NOM
CLIENT
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...
18
Exemple NOM
SDL
CLIENT
19
Les « toolkits » graphiques
NOM
CLIENT
●
●
Fournissent un ensemble d’objets graphiques
–
Menus
–
Boutons
–
Boîtes de dialogues
–
WebView
–
Mediaplayer
Exemples:
–
Athena widgets, OSF-Motif (X11) → obsolète
–
WxWidgets → obsolète
–
Qt
–
EFL (Enlightenment, E18)
–
GTK+
20
NOM
CLIENT
●
●
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)
21
Qt sur Mini2440
NOM
CLIENT
22
EFL
NOM
CLIENT
●
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
23
EFL au NOM
frigo
CLIENT
24
GTK+
NOM
CLIENT
●
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)
25
HTML NOM
CLIENT
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
26
Eco systeme brouillon
Android
NOM
CLIENT
●
●
●
●
●
●
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)
27
Questions?