Solutions IHM pour Linux embarqué. Contact :Jérémy ROSEN jeremy.rosen@openwide.fr

Transcription

1 Solutions IHM pour Linux embarqué Contact :Jérémy ROSEN jeremy.rosen@openwide.fr

2 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 Programme 2

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 3

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é 4

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 5

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 6

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 7

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... 8

9 Linux est un UNIX Mode texte par défaut «X Window System» ou X11 à partir de 84 Xorg à partir de 2004 Créé au MIT X11, 1/2 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

10 Initialement peu adapté à l embarqué Retour grâce à plusieurs éléments : X11, 2/2 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

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 11

12 Protocole de communication client/compositeur Le client dessine dans des buffers mémoire Wayland 2/3 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

13 Wayland Architecture Architecures comparées X/Wayland 13

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 14

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 15

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 16

17 Exemple DirectFB 17

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... 18

19 Exemple SDL 19

20 Fournissent un ensemble d objets graphiques Les «toolkits» 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

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) 21

22 Qt sur Mini

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 23

24 EFL au frigo 24

25 GTK+ 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

26 HTML 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

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) 27

28 Questions?

29 Solutions IHM pour Linux embarqué Contact :Jérémy ROSEN jeremy.rosen@openwide.fr

30 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 Programme 2

31 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 3

32 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é 4

33 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 5 Google glass (voix/écran) Smartwatch Android Wear

34 Développement d'une application embarquée Plusieurs approches 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

35 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 7

36 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... 8

37 Linux est un UNIX Mode texte par défaut «X Window System» ou X11 à partir de 84 X11, 1/2 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

38 Initialement peu adapté à l embarqué Retour grâce à plusieurs éléments : X11, 2/2 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

39 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 11 Modifier le dernier point.

40 Protocole de communication client/compositeur Le client dessine dans des buffers mémoire Wayland 2/3 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 ecture.html

41 Wayland Architecture Architecures comparées X/Wayland 13

42 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 14

43 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 15

44 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 16 Standard avec certains constructeurs de hardware (sigma)

45 Exemple DirectFB 17

46 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

47 Exemple SDL 19

48 Fournissent un ensemble d objets graphiques Les «toolkits» 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

49 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

50 Qt sur Mini

51 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 23

52 EFL au frigo 24

53 GTK+ 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

54 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 26 Eco systeme brouillon

55 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) 27

56 Questions?