Dépannage des écrans tactiles USB sous Linux : un workflow pratique avec evtest et libinput

Un écran tactile USB peut apparaître dans la liste des périphériques USB alors que l'application ne reçoit toujours aucune entrée tactile utilisable. Pour identifier la couche défaillante, testez le chemin dans l'ordre : identité du périphérique, nœud d'événement du noyau, événements de contact, libinput et l'application. Conservez le même écran tactile et les mêmes mouvements de test tout au long de la procédure afin que chaque comparaison réponde à une question spécifique.

Ce flux de dépannage pour écran tactile USB sous Linux couvre les contrôleurs tactiles qui exposent une interface evdev. Il utilise des commandes de diagnostic en lecture seule et propose une procédure de banc reproductible. Aucun écran tactile cible n'était connecté lors de la rédaction ; les commandes ont été vérifiées par rapport à la documentation, et la procédure ne constitue pas une qualification matérielle complète.

1. Enregistrer l'environnement et trouver le périphérique USB

Commencez avec un écran tactile connu lorsque cela est possible. Séparez la connexion d'affichage de la connexion tactile dans vos notes. Une image vidéo fonctionnelle ne prouve pas que le contrôleur tactile USB a été énuméré.

uname -r

Enregistrez la version du noyau et les outils disponibles. Les noms de paquets, les permissions d'accès et les versions d'outils varient selon la distribution. Si une commande est manquante, obtenez l'outil approprié via le processus documenté de votre distribution avant de poursuivre cette partie du test.

lsusb liste les périphériques USB.^[8] Faites correspondre une entrée de contrôleur plausible à la documentation matérielle ou à un enregistrement de périphérique existant. Un nom de produit peut être générique, conservez donc également les identifiants de fabricant et de produit. L'énumération USB seule ne prouve pas que le noyau a créé un nœud d'événement tactile ni que l'interface graphique peut l'utiliser.

Dans /proc/bus/input/devices, recherchez un périphérique d'entrée candidat et son gestionnaire d'événements. Linux expose les événements d'entrée du noyau à l'espace utilisateur via des nœuds evdev tels que /dev/input/event7.^[1] Un contrôleur peut exposer plus d'une interface d'entrée. Ne sélectionnez pas un nœud uniquement parce que son nom contient “ USB ”.”

Si l'identité USB attendue est absente, résolvez d'abord cette question d'énumération. Enregistrez la configuration de connexion et si le périphérique apparaît de manière cohérente. Les tests d'événements ultérieurs ne peuvent pas diagnostiquer un périphérique qui n'a pas de chemin d'entrée identifié.

2. Confirmer le nœud d'événement avant de capturer le toucher

Dans chaque commande ci-dessous, N est un espace réservé. Remplacez-le par le numéro d'événement identifié sur votre machine ; ne tapez pas la lettre N littéralement.

udevadm info --query=property --name=/dev/input/eventN

udevadm info lit les informations depuis la base de données des périphériques. Lorsqu'ils sont disponibles, les identifiants USB, un numéro de série ou le chemin du périphérique aident à relier le nœud au contrôleur.^[7] Les propriétés peuvent varier ou être absentes. Conservez la sortie avec la capture plutôt que de supposer qu'un numéro d'événement identifiera le même périphérique après une reconnexion.

evtest affiche les capacités du périphérique puis surveille les événements. La lecture du nœud nécessite souvent des permissions élevées.^[2] Utilisez les permissions appropriées à votre système de test. Ne modifiez pas le nœud pour un accès en écriture pour tous. Appuyez sur Ctrl+C pour terminer chaque session de surveillance.

Commencez avec tous les doigts levés. Touchez le centre une fois avec un doigt, puis levez. Confirmez que cette action produit des événements sur le nœud candidat. Lisez les capacités pour les axes absolus et les champs multi-touch éventuels. Un nœud qui n'expose que des contrôles non liés n'est pas l'interface tactile recherchée.

Si plusieurs nœuds restent plausibles, terminez une session et inspectez le candidat suivant. Tenez une note reliant chaque nœud à son identité et à la réponse observée. Cela évite d'interpréter le silence de la mauvaise interface comme une défaillance du contrôleur.

N'ajoutez pas --grab. Une capture exclusive modifie les clients qui reçoivent l'entrée et interférerait avec la comparaison ultérieure de l'application.

3. Lire le vocabulaire des événements avant de juger la trace

Les rapports d'entrée sont à état : les valeurs inchangées n'ont pas besoin de réapparaître. EV_ABS identifie les événements d'axe absolu, et SYN_REPORT sépare les trames d'entrée. SYN_DROPPED indique un débordement de la file d'événements du client.^[3] Une capture contenant ce marqueur est incomplète ; répétez une capture plus courte et signalez la perte. N'utilisez pas une séquence incomplète pour prouver un relâchement manquant ou un défaut matériel.

Lisez les limites d'axe imprimées pour le périphérique. Ce sont des unités d'entrée brutes, pas nécessairement des pixels LCD. Une valeur proche du maximum X brut ne signifie pas que l'application doit placer le pointeur à une coordonnée pixel numériquement identique.

Recherchez un cycle de vie de contact ainsi que des changements de position. Les champs exacts dépendent des capacités. Ne supposez pas que chaque périphérique rapporte la pression, prend en charge plusieurs contacts ou utilise le même protocole.

Pour un périphérique utilisant le protocole multi-touch de type B, les slots conservent leur état. Un ABS_MT_TRACKING_ID non négatif identifie un contact ; -1 marque son relâchement. ABS_MT_POSITION_X et ABS_MT_POSITION_Y décrire sa position. ABS_MT_SLOT peut être absent lorsque le slot sélectionné n'a pas changé.^[4]

Par conséquent, un doigt immobile n'a pas besoin de produire des coordonnées répétées. Une trace qui ne liste que le doigt en mouvement peut tout de même décrire deux contacts actifs. Reconstruire l'état conservé avant de déclarer l'autre doigt manquant.

4. Exécuter un test d'entrée brute à cinq points et deux traits

Conserver evtest l'exécution sur le nœud confirmé. Utiliser le protocole proposé suivant pour rendre les captures comparables entre les exécutions. Il vérifie la couverture de base et la continuité ; il ne fixe pas de seuil de précision universel.

1. Toucher le centre une fois, maintenir brièvement, puis relâcher complètement.
2. Répéter dans les zones supérieure gauche, supérieure droite, inférieure droite et inférieure gauche. Maintenir chaque point visiblement à l'intérieur de la zone tactile active plutôt que sur le bord.
3. Tracer un trait horizontal lent à travers la zone utilisable, puis relâcher.
4. Tracer un trait vertical lent, puis relâcher.
5. Répéter toute action douteuse seule dans une capture plus courte.

Pour chaque toucher, enregistrer si un nouveau contact apparaît, si sa position se situe dans les limites d'axe rapportées, et si le relâchement final met fin au contact. Comparer les positions entre les cinq points. Ils doivent former un motif spatial reproductible, mais les axes bruts peuvent différer en direction de l'image affichée. Documenter si chaque axe brut augmente ou diminue à chaque mouvement physique, puis comparer avec l'orientation prévue du projet. Le coin supérieur gauche physique ne correspond pas nécessairement aux deux minima d'axe sur un assemblage pivoté ou mis en miroir.

Pour chaque trait, rechercher une séquence de changements de position correspondant au mouvement. Enregistrer les sauts soudains, les fins de contact inattendues ou les valeurs qui cessent repeatedly de couvrir une partie de la zone prévue. Un trait physique horizontal peut principalement modifier l'autre axe brut sur un assemblage pivoté ; cette observation est une preuve utile, pas un défaut automatique.

Répéter le même mouvement si quelque chose semble anormal. Noter si l'anomalie se répète au même endroit ou se produit de manière imprévisible. L'un ou l'autre motif peut guider une investigation plus poussée, mais aucun ne permet à lui seul d'identifier le composant défaillant.

Une observation de base réussie se caractérise par une pression, un mouvement et un relâchement complets avec une couverture reproductible. Elle n'établit pas la précision de production, la latence, les performances environnementales ou la fiabilité à long terme. Ces éléments nécessitent des critères d'acceptation spécifiques à l'application et un plan de qualification distinct.

5. Tester plusieurs contacts uniquement lorsque cela est pris en charge

Procéder uniquement si la capacité documentée de l'appareil et l'interface d'événements prennent en charge le test multi-touch prévu. Dans le cas contraire, enregistrer la limitation plutôt que d'interpréter un résultat mono-contact comme un échec du test à deux doigts.

Pour un appareil de type B pris en charge, placer un doigt près du côté gauche et le maintenir immobile. Placer un second doigt près du côté droit. Déplacer uniquement le second doigt, le relâcher, puis déplacer et relâcher le premier. Enfin, répéter avec les rôles inversés.

Démarrer la capture avec les deux doigts relâchés, puis suivre les identités de contact et l'état de slot conservé à travers les trames. Les observations utiles sont deux contacts actifs distinguables, un mouvement associé au contact prévu, le relâchement d'un contact tandis que l'autre reste actif, et le relâchement du dernier contact. Le slot sélectionné ou les coordonnées d'un doigt immobile peuvent ne pas se répéter à chaque trame.

Maintenir les deux doigts suffisamment écartés pour rendre les actions prévues claires. Ce test vérifie si le cycle de vie rapporté suit la procédure. Il ne s'agit pas d'une certification du nombre de contacts ni d'une mesure d'espacement minimal.

Si la séquence brute est ambiguë, répéter uniquement la transition qui a suscité le doute. Une capture courte de “ second doigt posé, second doigt levé, premier doigt levé ” est plus facile à examiner qu'une longue session contenant de nombreux gestes sans rapport.

6. Comparer libinput avec les mêmes actions physiques

Terminer evtest, puis inspecter libinput :

sudo libinput list-devices

libinput list-devices affiche les appareils reconnus par libinput, leurs capacités et les valeurs par défaut intégrées. Il ne rapporte pas la configuration réelle du bureau.^[5] Trouver le nœud d'événement confirmé et inspecter sa capacité tactile rapportée. Ne pas se fier à une disposition fixe des colonnes de sortie pour l'analyse automatisée.

libinput debug-events surveille les événements dans un contexte séparé. Son comportement peut différer de celui du compositeur ou de l'application.^[6] Répéter le toucher central, le trait horizontal et le relâchement final. Si pris en charge, répéter la séquence à deux contacts. Terminer la session avec Ctrl+C.

Si le tactile brut est cohérent mais que libinput ne reconnaît pas le nœud comme prévu, conserver les deux sorties. L'investigation suivante concerne la reconnaissance, la classification ou l'environnement userspace testé. La comparaison a précisé la question ; elle n'a pas prouvé que le panneau ou le firmware du contrôleur est défectueux.

Si les deux outils montrent un tactile cohérent, passer à l'application réelle. Un test libinput séparé ne peut pas certifier l'association d'affichage, la rotation ou la gestion des événements applicatifs du compositeur.

7. Localiser la couche défaillante sans deviner un correctif

An open device handle does not prove an exclusive grab. Likewise, no events do not prove failed hardware: a wrong node, access condition, grab, or driver path can produce a silent capture. Avoid changing several settings at once; doing so removes the controlled comparison.

In the application, repeat the same five points and strokes. Record whether the mismatch affects the whole desktop, one output, or one application. Inspect the configuration actually used by that compositor or toolkit. This guide does not prescribe a universal calibration matrix.

8. Prepare a small, reproducible technical handoff

Provide the display and touch-controller models, USB identifiers, kernel release, tool versions, confirmed event node, and capability output. Include a short event excerpt tied to exact physical actions, plus the observed difference between raw input, libinput, and the application. State whether the capture contains any dropped-event marker.

Also describe the host, display orientation, connected outputs, touch connection, and application environment. Remove unrelated output. A concise reproduction gives another engineer a better starting point than a large log labeled only “touch does not work.”

For broader module requirements, see the guide des modules d'écran tactile; for a separate platform architecture discussion, see Android touch and HDMI touch. To request project-specific review, send RJY the model details and the bounded test record. RJY can discuss documented display and touch-module requirements from that record. Compatibility and any adaptation of an existing module still require verification for the actual controller, host, software, and application.

Références

1. Linux kernel documentation: input subsystem introduction.
2. Debian manual: evtest.
3. Linux kernel documentation: input event codes.
4. Linux kernel documentation: multi-touch protocol.
5. libinput documentation: helper tools.
6. Debian manual: libinput debug-events.
7. systemd documentation: udevadm.
8. Debian manual: lsusb.