Anforderungen an das Laufzeitziel für Qt für QNX

QNX Software Systems bietet Softwarelösungen für die Entwicklung eingebetteter Geräte an. Dazu gehört auch die Erstellung von QNX Neutrino RTOS-Boot-Images auf sehr flexible Weise. Auch wenn QNX mehrere Referenzskripte für die Erstellung von Betriebssystem-Images bereitstellt, werden Sie früher oder später Änderungen vornehmen müssen oder sich möglicherweise dafür entscheiden, ein Betriebssystem-Image von Grund auf neu zu erstellen. Qt ist auf das Vorhandensein mehrerer Komponenten von Drittanbietern und ausgewählter Betriebssystemdienste angewiesen. Aus diesem Grund müssen QNX-Neutrino-RTOS-Boot-Images für ein Zielgerät, auf dem Qt ausgeführt wird, die in den folgenden Abschnitten aufgeführten Anforderungen erfüllen, um sicherzustellen, dass Qt wie erwartet funktioniert.

QNX-Bildschirmgrafiksubsystem

Bevor eine Qt-Anwendung gestartet werden kann, muss das QNX-Bildschirmgrafiksubsystem (auch einfach „Screen“ genannt) laufen. „ Screen “ besteht aus einem Treiber sowie mehreren Dienstprogrammen und Diensten, die von Qt genutzt werden. Dazu gehört auch die Verarbeitung von Maus- und Tastaturereignissen. Sie können sicherstellen, dass „ Screen “ korrekt konfiguriert ist und läuft, indem Sie überprüfen, ob sich eine Grafikanwendung wie „ gles2-gears “ starten lässt und problemlos läuft.

Die meisten der neueren Beispiel-Build-Skripte für Betriebssysteme im SDP enthalten Abschnitte mit allen Komponenten und Startbefehlen für den Screen. Sie können diese als Referenz verwenden.

Vulkan

Wenn Sie Vulkan-Rendering verwenden, muss das Ziel-Image einen Vulkan-Loader (libvulkan.so) und einen Screen -Grafiktreiber bereitstellen, der die Erweiterung „ VK_QNX_screen_surface “ implementiert. Weitere Informationen finden Sie unter „Vulkan-Rendering-APIs“.

IPv6-Unterstützung

Der Netzwerkstack von Qt erfordert, dass die IPv6-Unterstützung aktiviert ist, unabhängig davon, ob das eigentliche Netzwerk IPv4 oder IPv6 verwendet.

Zufälliges Gerät /dev/random

Qt setzt voraus, dass „ /dev/random “ vorhanden und funktionsfähig ist. Starten Sie es vor dem Start einer Qt-Anwendung oder während des Systemstarts:

random -p
waitfor /dev/random

System-Logger

QNX stellt das Protokollierungs-Framework „slog2“ bereit, das speziell auf die Anforderungen eingebetteter Systeme zugeschnitten ist. Der wesentliche Vorteil besteht in einer deutlich besseren Leistung als bei einer Textausgabe in Dateien. Qt nutzt dieses Framework standardmäßig für alle Protokollausgaben, die unter dem QNX Neutrino RTOS über „ QDebug “ laufen. Der Dienst „ slog2 “ sollte beim Systemstart gestartet werden. Die Datei „ slog2 “ setzt zudem das Vorhandensein des Ordners „ /tmp “ voraus, der ebenfalls konfiguriert werden muss, zum Beispiel:

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

Umgebungsvariablen

Es gibt eine Reihe von Umgebungsvariablen, die Sie beim Starten einer Qt-Anwendung setzen sollten. Die meisten davon sind eigentlich nicht spezifisch für das QNX Neutrino RTOS. Sie werden hier dennoch erwähnt, da ihre Kenntnis im Falle von Problemen viel Zeit spart.

Speicherort der Qt-Laufzeitkomponenten

Wenn Sie Qt nicht mit gesetzter RPATH-Umgebungsvariable kompiliert haben, können Sie die Qt-Laufzeitkomponenten in einem beliebigen Ordner im Dateisystem ablegen. Die folgenden Umgebungsvariablen sollten auf gültige Speicherorte verweisen, vorausgesetzt, die Qt-Installation befindet sich unter <Qt-install-path>:

• LD_LIBRARY_PATH sollte den Pfad zu den Qt-Bibliotheken unter <Qt-install-path>/lib enthalten.
• QT_PLUGIN_PATH legt fest, wo sich die Qt-Plug-ins befinden. Sie sollte auf ` <Qt-install-path>/plugins` gesetzt werden.
• QML2_IMPORT_PATH Legt fest, wo sich die „ Qt Quick “-Plug-ins befinden. Sie sollte auf „ <Qt-install-path>/qml “ gesetzt werden.
• Wenn Qt fontconfig nicht verwendet, müssen Sie entweder den Pfad zu den Schriftarten mit „ QT_QPA_FONTDIR “ angeben oder die Schriftarten unter „ <Qt-install-path>/lib/fonts “ ablegen, dem Standardverzeichnis für Schriftarten.
• Überprüfen Sie unter „ QT_QPA_QNX_DISPLAY_CONFIG “ die Anzahl und Reihenfolge der verfügbaren Bildschirme/Anzeigen.

Physikalische Bildschirmgröße

Qt benötigt Informationen über die physikalischen Abmessungen des angeschlossenen Bildschirms, um DPI-Werte zu ermitteln und somit die richtigen Schriftgrößen festzulegen. In der Regel werden diese Informationen vom Bildschirm bereitgestellt. In einigen Fällen kann es vorkommen, dass eine ungültige Bildschirmgröße wie z. B. 0 mm × 0 mm angezeigt wird. In einem solchen Fall benötigt Qt eine Umgebungsvariable „ QQNX_PHYSICAL_SCREEN_SIZE “, die auf entsprechende Werte gesetzt ist, um die erforderlichen Informationen zu erhalten. Wenn Qt-Anwendungen mit einer Fehlermeldung beendet werden, die besagt, dass die physische Bildschirmgröße nicht ermittelt werden konnte, setzen Sie die Variable vor dem Start der Qt-Anwendung wie folgt:

export QQNX_PHYSICAL_SCREEN_SIZE=150,100

um Qt mitzuteilen, dass der Bildschirm in diesem speziellen Fall eine Breite von 150 mm und eine Höhe von 100 mm hat. Die physische Bildschirmgröße wird in Millimetern (mm) gemessen und sollte der tatsächlichen physischen Größe des Displays in der endgültigen Konfiguration entsprechen.

Fehlerbehebung beim ersten Start einer Qt-Anwendung

Der einzige Nachteil der von QNX Neutrino RTOS gebotenen Flexibilität ist das Risiko, dass die Laufzeitumgebung auf Ihrem Zielsystem leicht von den Erwartungen von Qt abweicht. Dies ist ein häufiger Grund dafür, dass eine Qt-Anwendung auf einem neuen Zielsystem nicht gestartet werden kann. Einige allgemeine Umgebungsvariablen können dabei helfen, die Ursache für Probleme zu ermitteln:

• Das Setzen von „ QT_DEBUG_PLUGINS “ auf „ 1 “ hilft dabei, festzustellen, warum das QPA-Plugin nicht geladen werden kann.
• Die Einstellung von ` LD_DEBUG ` auf ` 1 ` hilft dabei, festzustellen, wo und wie gemeinsam genutzte Bibliotheken geladen werden. Dies kann in Kombination mit ` QT_DEBUG_PLUGINS ` verwendet werden, wenn ein Plugin nicht geladen werden konnte, weil es andere gemeinsam genutzte Bibliotheken nicht laden konnte.
• Durch die Einstellung von ` QT_LOGGING_TO_CONSOLE ` werden alle Protokollmeldungen zwingend an ` stderr ` statt an ` slog2` gesendet. Dies ist nützlich für die Analyse von Problemen beim Anwendungsstart, da Sie kein weiteres Tool benötigen, um die Meldungen einzusehen.

Qt verwendet normalerweise „ fontconfig “, um Zugriff auf Systemschriftarten zu gewähren. Falls zuvor noch kein Schriftartencache angelegt wurde, wird dieser beim Start der ersten Qt-Anwendung erstellt. Je nach Konfiguration kann dies sehr lange dauern und den Start von Anwendungen erheblich verzögern. Falls nicht benötigt, kann fontconfig bei der Konfiguration mit -DFEATURE_fontconfig=OFF deaktiviert werden.

Verwendung von QCursor auf der QNX-Plattform

Die Unterstützung für benutzerdefinierte Cursor ist auf QNX standardmäßig deaktiviert. Um sie zu aktivieren, setzen Sie vor dem Start Ihrer Qt-Anwendung die Umgebungsvariable ` QT_QPA_QNX_CUSTOM_CURSOR `:

export QT_QPA_QNX_CUSTOM_CURSOR=1

Wenn die Unterstützung für benutzerdefinierte Cursor aktiviert ist, unterstützt QNX die Änderung der Cursorform für ein Fenster; Sie müssen jedoch die Bilder, die den von Ihnen gewünschten Formen zugeordnet sind, über die Bildschirmkonfigurationsdatei „ graphics.conf “ bereitstellen und angeben. Weitere Details finden Sie im Unterabschnitt „Cursortyp“ des Abschnitts „Anzeige konfigurieren “. Abgesehen vom Standardcursor werden in QNX keine zusätzlichen Cursor bereitgestellt. Daher müssen alle zusätzlichen Cursor-Grafiken manuell im Bitmap-Format bereitgestellt werden. Die folgende Tabelle zeigt den in „ graphics.conf “ verwendeten Cursornamen für jeden Wert von „ Qt::CursorShape “.