Configuration requise pour la cible d'exécution Qt pour QNX

QNX Software Systems propose des solutions logicielles pour la conception d’appareils embarqués. Cela inclut la création d’images de démarrage du système d’exploitation temps réel (RTOS) QNX Neutrino de manière très flexible. Même si QNX fournit plusieurs scripts de référence pour la création d’images du système d’exploitation, vous devrez tôt ou tard apporter des modifications ou vous pourriez décider de créer une image du système d’exploitation à partir de zéro. Qt repose sur l’existence de plusieurs composants tiers et de certains services du système d’exploitation. De ce fait, les images de démarrage du système d’exploitation temps réel QNX Neutrino destinées à un appareil cible exécutant Qt doivent répondre aux exigences énumérées dans les sections suivantes afin de garantir que Qt fonctionne comme prévu.

Sous-système graphique QNX « Screen »

Avant de pouvoir lancer une application Qt, le sous-système graphique d’écran QNX (également appelé simplement « Screen ») doit être en cours d’exécution. Screen se compose d’un pilote ainsi que de plusieurs utilitaires et services utilisés par Qt. Cela inclut également le traitement des événements de souris et de clavier. Vous pouvez vous assurer que Screen est correctement configuré et fonctionne en vérifiant qu’une application graphique, telle que gles2-gears, peut être lancée et s’exécute sans problème.

La plupart des scripts de compilation d'exemples de systèmes d'exploitation récents inclus dans le SDP comportent des sections contenant tous les composants et les commandes de démarrage pour Screen. Vous pouvez vous y référer.

Vulkan

Si vous utilisez le rendu Vulkan, l’image cible doit fournir un chargeur Vulkan (libvulkan.so) et un pilote graphique Screen qui implémente l’extension VK_QNX_screen_surface. Pour plus d’informations, consultez la documentation sur les API de rendu Vulkan.

Prise en charge d’IPv6

La pile réseau de Qt nécessite que la prise en charge d’IPv6 soit activée, que le réseau utilise effectivement IPv4 ou IPv6.

Périphérique aléatoire /dev/random

Qt nécessite que le service /dev/random soit présent et opérationnel. Lancez-le avant de démarrer toute application Qt ou lors du démarrage du système :

random -p
waitfor /dev/random

Journalisation système

QNX fournit le framework de journalisation slog2, spécialement adapté aux spécificités des systèmes embarqués. Son principal avantage réside dans des performances nettement supérieures à celles d’une sortie texte vers des fichiers. Qt utilise ce framework par défaut pour toute sortie de journalisation transitant par QDebug sur le système d’exploitation temps réel QNX Neutrino. Le service slog2 doit être lancé lors du démarrage du système. L’ slog2 dépend également de l’existence du dossier /tmp, qui doit également être configuré, par exemple :

[type=link] /tmp=/dev/shmem
display_msg "Starting slogger2..."
slogger2 -U1001:1000 &
waitfor /dev/slog2

Variables d’environnement

Il existe un ensemble de variables d’environnement que vous devez définir lors du lancement d’une application Qt. La plupart d’entre elles ne sont en réalité pas spécifiques au système d’exploitation temps réel QNX Neutrino. Elles sont néanmoins mentionnées ici, car leur connaissance permet de gagner beaucoup de temps en cas de problèmes.

Emplacement du runtime Qt

Si vous n’avez pas compilé Qt en définissant la variable d’environnement RPATH, vous pouvez placer les composants d’exécution Qt dans n’importe quel dossier du système de fichiers. Les variables d’environnement suivantes doivent pointer vers des emplacements valides, en supposant que l’installation de Qt se trouve dans <Qt-install-path>:

• LD_LIBRARY_PATH doit contenir le chemin d'accès aux bibliothèques Qt dans <Qt-install-path>/lib.
• QT_PLUGIN_PATH définit l’emplacement des plug-ins Qt. Elle doit être définie sur <Qt-install-path>/plugins.
• QML2_IMPORT_PATH définit l’emplacement des plug-ins Qt Quick. Elle doit être définie sur <Qt-install-path>/qml.
• Si Qt n'utilise pas fontconfig, vous devez soit indiquer le chemin d'accès aux polices avec QT_QPA_FONTDIR, soit placer les polices dans <Qt-install-path>/lib/fonts, qui est l'emplacement par défaut des polices.
• Vérifiez QT_QPA_QNX_DISPLAY_CONFIG pour connaître le nombre et l'ordre des écrans/affichages disponibles.

Taille physique de l'écran

Qt a besoin d’informations sur les dimensions physiques de l’écran connecté pour déterminer les valeurs DPI et ainsi définir correctement la taille des polices. Généralement, ces informations sont fournies par l’objet Screen. Dans certains cas, vous pouvez rencontrer une taille d’écran invalide, telle que 0 mm × 0 mm. Dans ce cas, Qt nécessite que la variable d’environnement QQNX_PHYSICAL_SCREEN_SIZE soit définie sur les valeurs appropriées pour obtenir les informations requises. Si les applications Qt se ferment avec un message d’erreur indiquant que la taille physique de l’écran n’a pas pu être déterminée, définissez la variable comme suit avant de lancer l’application Qt :

export QQNX_PHYSICAL_SCREEN_SIZE=150,100

pour indiquer à Qt que l'écran a une largeur de 150 mm et une hauteur de 100 mm dans ce cas particulier. La taille physique de l'écran est mesurée en millimètres (mm) et doit correspondre à la taille physique réelle de l'écran dans la configuration finale.

Dépannage du premier démarrage d’une application Qt

Le seul inconvénient de la flexibilité offerte par le système d’exploitation temps réel QNX Neutrino réside dans le risque que l’environnement d’exécution sur votre cible soit légèrement différent de ce à quoi s’attend Qt. C’est une cause fréquente d’échec au démarrage d’une application Qt sur une nouvelle cible. Quelques variables d’environnement génériques peuvent aider à identifier la cause première des problèmes :

• Définir ` QT_DEBUG_PLUGINS ` sur ` 1 ` permet de comprendre pourquoi le plugin QPA ne parvient pas à se charger.
• Définir ` LD_DEBUG ` sur ` 1 ` permet de voir où et comment les bibliothèques partagées sont chargées. Cette option peut être utilisée en combinaison avec ` QT_DEBUG_PLUGINS ` lorsqu’un plugin n’a pas pu se charger car il n’a pas pu charger d’autres bibliothèques partagées.
• La configuration de ` QT_LOGGING_TO_CONSOLE ` force l'envoi de tous les messages de journalisation vers ` stderr ` au lieu de ` slog2`. Cela s'avère utile pour analyser les problèmes de démarrage de l'application, car vous n'avez pas besoin d'utiliser un autre outil pour consulter les messages.

Qt utilise normalement fontconfig pour accéder aux polices système. Si aucun cache de polices n’a été créé auparavant, il sera créé au démarrage de la première application Qt. Selon la configuration, cela peut prendre beaucoup de temps et retarder considérablement le démarrage des applications. Si cela n’est pas nécessaire, fontconfig peut être désactivé avec l’option -DFEATURE_fontconfig=OFF lors de la configuration.

Utilisation de QCursor sur la plate-forme QNX

La prise en charge des curseurs personnalisés sur QNX est désactivée par défaut. Pour l’activer, définissez la variable d’environnement ` QT_QPA_QNX_CUSTOM_CURSOR ` avant de lancer votre application Qt :

export QT_QPA_QNX_CUSTOM_CURSOR=1

Lorsque la prise en charge des curseurs personnalisés est activée, QNX permet de modifier la forme du curseur d’une fenêtre, mais vous devrez déployer et spécifier les images associées aux formes que vous souhaitez utiliser via le fichier de configuration d’écran, graphics.conf. Reportez-vous au paramètre cursor-type de la sous-section « Configurer l’affichage » pour plus de détails. Outre le curseur par défaut, aucun autre curseur n’est fourni dans QNX. Par conséquent, tout graphique de curseur supplémentaire doit être fourni manuellement au format bitmap. Le tableau ci-dessous indique le nom de curseur utilisé dans ` graphics.conf ` pour chaque valeur de ` Qt::CursorShape `.