Entrées sur un appareil Linux embarqué

Sur votre périphérique Linux embarqué, en l'absence de système de fenêtrage, les entrées de la souris, du clavier et de l'écran tactile sont lues directement via evdev ou à l'aide de bibliothèques auxiliaires telles que libinput ou tslib. Toutefois, ce comportement nécessite que les nœuds de périphériques /dev/input/event* soient accessibles en lecture par l'utilisateur. eglfs et linuxfb intègrent tout le code de gestion des entrées.

Utilisation de libinput

libinput est une bibliothèque de gestion des périphériques d’entrée qui offre une alternative à la prise en charge des périphériques d’entrée de Qt ( evdev ). Pour activer l’utilisation de libinput, lorsque vous configurez et compilez Qt, assurez-vous que les fichiers de développement de libudev et libinput sont disponibles. Si vous avez besoin d’une prise en charge du clavier, le fichier xkbcommon est également nécessaire. Avec eglfs et linuxfb, aucune autre action n’est nécessaire, car ces plugins utilisent libinput par défaut. Si la prise en charge de libinput n’est pas disponible ou si la variable d’environnement QT_QPA_EGLFS_NO_LIBINPUT est définie, ce sont alors les gestionnaires evdev propres à Qt qui sont utilisés à la place.

Les variables d’environnement suivantes sont disponibles lorsque des événements d’entrée sont reçus via libinput:

Saisie sur eglfs et linuxfb sans libinput

Des paramètres tels que le nom du nœud de périphérique peuvent être définis dans les variables d'environnement QT_QPA_EVDEV_MOUSE_PARAMETERS, QT_QPA_EVDEV_KEYBOARD_PARAMETERS et QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS; séparez vos entrées par des deux-points. Ces paramètres constituent une alternative au passage des paramètres dans l'argument de ligne de commande -plugin, et ils sont indispensables avec certains backends. Cependant, eglfs et linuxfb utilisent des gestionnaires d'entrée intégrés ; il n'y a donc pas d'argument -plugin distinct utilisé.

De plus, les gestionnaires d’entrée intégrés peuvent être désactivés en définissant QT_QPA_EGLFS_DISABLE_INPUT (pour eglfs) ou QT_QPA_FB_DISABLE_INPUT (pour linuxfb) sur 1.

Souris

Le curseur de souris s'affiche dès lors que QT_QPA_EGLFS_HIDECURSOR (pour eglfs) ou QT_QPA_FB_HIDECURSOR (pour linuxfb) n'est pas défini et que la détection de périphériques de Qt, basée sur libudev, signale qu'au moins une souris est disponible. Lorsque la prise en charge de libudev n'est pas présente, le curseur de souris s'affiche systématiquement, sauf s'il est explicitement désactivé via la variable d'environnement.

Si Qt a été configuré avec la prise en charge de libudev, la connexion ou la déconnexion d’un périphérique d’entrée pendant l’exécution de l’application (connexion à chaud) est prise en charge. Dans ce cas, les en-têtes de développement libudev sont présents dans le sysroot au moment de la configuration.

Le gestionnaire de souris « evdev » prend en charge les paramètres supplémentaires suivants :

Clavier

Le gestionnaire de clavier « evdev » prend en charge les paramètres supplémentaires suivants :

Sur les systèmes Linux embarqués dont les sessions de terminal ne sont pas désactivées, le comportement lors de l'appui sur une touche peut prêter à confusion, car l'événement d'entrée est traité à la fois par l'application Qt et par le tty. Pour remédier à cela, les options suivantes sont disponibles :

• Au démarrage de l'application, les options ` EGLFS ` et ` LinuxFB ` tentent de désactiver le clavier du terminal en définissant le mode clavier du tty sur ` K_OFF`. Cela empêche l'envoi des frappes au terminal. Si le comportement standard est requis, définissez la variable d'environnement ` QT_QPA_ENABLE_TERMINAL_KEYBOARD ` sur ` 1`. Notez que cela ne fonctionne que lorsque l'application est lancée depuis une console distante, via ` ssh ` par exemple, et que la saisie au clavier du terminal reste activée.
• Une autre approche consiste à utiliser le paramètre ` grab ` du gestionnaire de clavier ` evdev ` en lui transmettant ` grab=1 ` dans ` QT_QPA_EVDEV_KEYBOARD_PARAMETERS`. Cela entraîne une tentative de prise de contrôle du périphérique d’entrée. Si la ` grab ` aboutit, aucun autre composant du système ne reçoit d’événements provenant de celui-ci, tant que l’application Qt est en cours d’exécution. Cette approche est plus adaptée aux applications qui démarrent à distance, car elle ne nécessite pas d’accès au périphérique tty.
• Enfin, pour de nombreuses images Linux embarquées spécialisées, il n’est pas judicieux d’activer les sessions de terminal standard. Pour plus de détails sur la manière de désactiver ces sessions de terminal, consultez la documentation de votre environnement de compilation. Par exemple, lors de la génération d’images à l’aide du projet Yocto, le fait de désactiver l’option ` SYSVINIT_ENABLED_GETTYS ` empêche l’exécution du processus ` getty `. Cela signifie qu’aucune entrée n’est prise en compte sur aucun des terminaux virtuels.

Si la configuration de clavier intégrée par défaut ne suffit pas, vous pouvez en spécifier une autre via le paramètre ` keymap `.

Pour générer une carte de touches personnalisée, utilisez l’utilitaire kmap2qmap, disponible dans le module qttools. Les fichiers source doivent être au format standard Linux kmap, pris en charge par la commande loadkeys du noyau. Les fichiers qmap peuvent être générés de l’une des manières suivantes :

• Le projet Linux Console Tools (LCT).
• Les configurations de clavierX.org X11 peuvent être converties au format kmap à l’aide de l’utilitaire ckbcomp.
• Les fichiers « kmap » étant des fichiers en texte brut, ils peuvent également être créés manuellement.

kmap2qmap est un programme en ligne de commande qui nécessite au moins deux fichiers comme paramètres. Le dernier paramètre correspond au fichier « .qmap » généré, tandis que tous les autres sont interprétés comme des fichiers « .kmap » d’entrée. Par exemple :

kmap2qmap i386/qwertz/de-latin1-nodeadkeys.kmap include/compose.latin1.inc de-latin1-nodeadkeys.qmap

Tactile

Bien que cela ne soit pas nécessaire pour les écrans tactiles modernes, certains écrans tactiles résistifs plus anciens qui ne prennent en charge que le toucher unique peuvent vous obliger à recourir à tslib, au lieu de vous fier au protocole multitouch de Linux et aux périphériques d’événements.

Pour activer la prise en charge d’ tslib, définissez la variable d’environnement QT_QPA_EGLFS_TSLIB (pour eglfs) ou QT_QPA_FB_TSLIB (pour linuxfb) sur 1. Pour changer de périphérique, définissez la variable d’environnement TSLIB_TSDEVICE ou indiquez le nom du périphérique sur la ligne de commande. Notez que le gestionnaire d’entrée tslib génère des événements de souris et ne prend en charge que le toucher unique, contrairement à evdevtouch qui génère également de véritables événements multi-touch QTouchEvent.

Le gestionnaire tactile d’ evdev prend en charge les paramètres supplémentaires suivants :

Par exemple, si vous transmettez les valeurs suivantes à ` QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS ` avant de lancer des applications, vous disposerez d'un périphérique tactile explicitement spécifié dont les coordonnées seront inversées. Cela s'avère utile lorsque l'orientation de l'écran physique et celle de l'écran tactile ne correspondent pas.

export QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event5:rotate=180

Tablettes à stylet

Le plugin evdevtablet offre une prise en charge de base des tablettes à stylet Wacom et similaires. Il génère uniquement des événements « QTabletEvent ». Pour l’activer, définissez QT_QPA_GENERIC_PLUGINS=evdevtablet dans l’environnement ou, à défaut, passez l’argument -plugin evdevtablet sur la ligne de commande.

Le plugin peut accepter un paramètre de nœud de périphérique, tel que QT_QPA_GENERIC_PLUGINS=evdevtablet:/dev/event1, si la détection automatique des périphériques de Qt (basée soit sur libudev, soit sur la traversée de /dev/input/event*) ne fonctionne pas ou présente des dysfonctionnements.

Périphériques d’entrée de débogage

Il est possible d’afficher certaines informations dans la sortie de débogage en activant la règle de journalisation « qt.qpa.input », par exemple en définissant la variable d’environnement « QT_LOGGING_RULES » sur « qt.qpa.input=true ». Cela s’avère utile pour détecter quel périphérique est utilisé ou pour résoudre les problèmes liés à la détection des périphériques.

Pour une journalisation plus détaillée des sous-systèmes d’entrée (souris, clavier, écran tactile), activez toutes les catégories de journalisation liées à l’entrée à l’aide de :

export QT_LOGGING_RULES="qt.qpa.input.*=true;qt.qpa.events=true"

Utiliser des images de curseur de souris personnalisées

eglfs est fourni avec son propre ensemble d’images de curseurs de souris au format 32x32. Si celles-ci ne suffisent pas, vous pouvez fournir un atlas de curseurs personnalisé en définissant la variable d’environnement ` QT_QPA_EGLFS_CURSOR ` sur le nom d’un fichier JSON. Ce fichier peut également être intégré à l’application via le système de ressources Qt.

Par exemple, un atlas de curseurs intégré contenant 8 images de curseurs par ligne peut être spécifié comme suit :

{
  "image": ":/cursor-atlas.png",
  "cursorsPerRow": 8,
  "hotSpots": [
      [7, 2],
      [12, 3],
      [12, 12],
      ...
  ]
}

Notez que les images doivent être étroitement regroupées dans l’atlas ; la largeur et la hauteur des curseurs sont déterminées en fonction de la taille totale de l’image et du paramètre cursorsPerRow. Les atlas doivent également fournir une image pour tous les curseurs pris en charge.

Les clés ` image ` et ` hotSpots `, ainsi qu’une valeur non nulle pour ` cursorsPerRow `, sont toutes obligatoires ; de plus, ` hotSpots ` doit comporter une entrée pour chaque forme de curseur prise en charge. Un fichier dans lequel l’un de ces éléments est manquant est rejeté avec un avertissement et le curseur est désactivé.