Linux USB-Touchscreen-Fehlerbehebung: Ein praktischer evtest- und libinput-Workflow

Ein USB-Touchscreen kann in der USB-Geräteliste erscheinen, während die Anwendung dennoch keine nutzbaren Touch-Eingaben erhält. Um die fehlerhafte Ebene zu finden, testen Sie den Pfad der Reihe nach: Geräteidentität, Kernel-Ereignisknoten, Kontaktereignisse, libinput und die Anwendung. Verwenden Sie durchgehend denselben Touchscreen und dieselben Testbewegungen, damit jeder Vergleich eine spezifische Frage beantwortet.

Dieser Linux-USB-Touchscreen-Fehlerbehebungsablauf deckt Touch-Controller ab, die eine evdev-Schnittstelle bereitstellen. Er verwendet schreibgeschützte Diagnosebefehle und schlägt ein reproduzierbares Bench-Verfahren vor. Während der Erstellung war kein Ziel-Touchscreen angeschlossen; die Befehle wurden anhand der Dokumentation geprüft, und das Verfahren ist keine abgeschlossene Hardware-Qualifizierung.

1. Umgebung erfassen und das USB-Gerät finden

Beginnen Sie nach Möglichkeit mit einem bekannten Touchscreen. Trennen Sie in Ihren Notizen die Display-Verbindung von der Touch-Verbindung. Ein funktionierendes Videobild belegt nicht, dass der USB-Touch-Controller enumeriert wurde.

uname -r

Erfassen Sie die Kernel-Version und welche Werkzeuge verfügbar sind. Paketnamen, Zugriffsberechtigungen und Werkzeugversionen variieren je nach Distribution. Wenn ein Befehl fehlt, beschaffen Sie das entsprechende Werkzeug über den dokumentierten Prozess Ihrer Distribution, bevor Sie diesen Teil des Tests durchführen.

lsusb listet USB-Geräte auf.^[8] Ordnen Sie einen plausiblen Controller-Eintrag der Hardware-Dokumentation oder einem vorhandenen Gerätedatensatz zu. Ein Produktname kann generisch sein, daher sollten Sie auch Hersteller- und Produktkennungen beibehalten. Die USB-Enumeration allein beweist nicht, dass der Kernel einen Touch-Ereignisknoten erstellt hat oder dass die GUI ihn verwenden kann.

In /proc/bus/input/devices, Suchen Sie nach einem Kandidaten-Eingabegerät und seinem Ereignis-Handler. Linux stellt Kernel-Eingabeereignisse für den Userspace über evdev-Knoten wie /dev/input/event7.^[1] bereit. Ein Controller kann mehr als eine Eingabeschnittstelle bereitstellen. Wählen Sie einen Knoten nicht allein deshalb aus, weil sein Name “USB” enthält.”

Wenn die erwartete USB-Identität fehlt, klären Sie zunächst diese Enumerationsfrage. Erfassen Sie die Verbindungsanordnung und ob das Gerät konsistent erscheint. Die späteren Ereignistests können ein Gerät nicht diagnostizieren, das keinen identifizierten Eingabepfad hat.

2. Den Ereignisknoten bestätigen, bevor Touch erfasst wird

In jedem der folgenden Befehle, N ist ein Platzhalter. Ersetzen Sie ihn durch die auf Ihrem System identifizierte Ereignisnummer; geben Sie den Buchstaben N nicht wörtlich ein.

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

udevadm info liest Informationen aus der Gerätedatenbank. Sofern verfügbar, helfen USB-Kennungen, eine Seriennummer oder der Gerätepfad dabei, den Knoten dem Controller zuzuordnen.^[7] Eigenschaften können variieren oder fehlen. Bewahren Sie die Ausgabe zusammen mit der Aufzeichnung auf, anstatt anzunehmen, dass eine Ereignisnummer nach einem erneuten Verbinden dasselbe Gerät identifiziert.

evtest gibt die Gerätefähigkeiten aus und überwacht dann Ereignisse. Das Lesen des Knotens erfordert häufig erhöhte Berechtigungen.^[2] Verwenden Sie die für Ihr Testsytem angemessenen Berechtigungen. Ändern Sie den Knoten nicht auf weltweit schreibbaren Zugriff. Drücken Sie Strg+C , um jede Überwachungssitzung zu beenden.

Beginnen Sie mit allen angehobenen Fingern. Berühren Sie die Mitte einmal mit einem Finger und heben Sie dann ab. Bestätigen Sie, dass diese Aktion Ereignisse auf dem Kandidatenknoten erzeugt. Lesen Sie die Fähigkeiten für absolute Achsen und etwaige Multi-Touch-Felder. Ein Knoten, der nur unzusammenhängende Steuerelemente bereitstellt, ist nicht die benötigte Touch-Schnittstelle.

Wenn mehrere Knoten plausibel bleiben, beenden Sie eine Sitzung und untersuchen Sie den nächsten Kandidaten. Führen Sie eine Notiz, die jeden Knoten mit seiner Identität und der beobachteten Reaktion verknüpft. Dies vermeidet, dass Stille von der falschen Schnittstelle als Controller-Ausfall interpretiert wird.

Fügen Sie nicht --grab. hinzu. Ein exklusiver Grab ändert, welche Clients Eingaben erhalten, und würde den späteren Anwendungsvergleich beeinträchtigen.

3. Das Ereignisvokabular lesen, bevor die Aufzeichnung beurteilt wird

Eingabeberichte sind zustandsbehaftet: Unveränderte Werte müssen nicht erneut erscheinen. EV_ABS kennzeichnet Ereignisse absoluter Achsen, und SYN_REPORT trennt Eingabe-Frames. SYN_DROPPED zeigt einen Überlauf der Ereigniswarteschlange des Clients an.^[3] Eine Aufzeichnung, die diesen Marker enthält, ist unvollständig; wiederholen Sie eine kürzere Aufzeichnung und melden Sie den Verlust. Verwenden Sie keine unvollständige Sequenz, um ein fehlendes Loslassen oder einen Hardwarefehler zu belegen.

Lesen Sie die für das Gerät ausgegebenen Achsengrenzen. Dies sind rohe Eingabeeinheiten, nicht unbedingt LCD-Pixel. Ein Wert nahe dem rohen X-Maximum bedeutet nicht, dass die Anwendung den Zeiger auf eine numerisch identische Pixelkoordinate setzen sollte.

Achten Sie sowohl auf einen Kontakt-Lebenszyklus als auch auf Positionsänderungen. Die genauen Felder hängen von den Fähigkeiten ab. Nehmen Sie nicht an, dass jedes Gerät Druck meldet, mehrere Kontakte unterstützt oder dasselbe Protokoll verwendet.

Bei einem Gerät, das das Multi-Touch-Protokoll Typ B verwendet, behalten Slots ihren Zustand. Eine nichtnegative ABS_MT_TRACKING_ID identifiziert einen Kontakt; -1 kennzeichnet dessen Loslassen. ABS_MT_POSITION_X und ABS_MT_POSITION_Y Beschreiben Sie seine Position. ABS_MT_SLOT kann fehlen, wenn sich der ausgewählte Slot nicht geändert hat.^[4]

Folglich muss ein stationärer Finger keine wiederholten Koordinaten erzeugen. Eine Spur, die nur den sich bewegenden Finger auflistet, kann dennoch zwei aktive Kontakte beschreiben. Rekonstruieren Sie den beibehaltenen Zustand, bevor Sie den anderen Finger als fehlend melden.

4. Führen Sie einen Rohdaten-Eingabetest mit fünf Punkten und zwei Strichen durch

Beibehalten evtest auf dem bestätigten Knoten ausgeführt wird. Verwenden Sie das folgende vorgeschlagene Protokoll, um Aufzeichnungen zwischen Durchläufen vergleichbar zu machen. Es prüft die grundlegende Abdeckung und Kontinuität; es legt keinen universellen Genauigkeitsschwellenwert fest.

1. Tippen Sie einmal in die Mitte, halten Sie kurz und heben Sie vollständig ab.
2. Wiederholen Sie dies in den Bereichen oben links, oben rechts, unten rechts und unten links. Halten Sie jeden Punkt sichtbar innerhalb der aktiven Berührungsfläche und nicht auf dem Rahmen.
3. Zeichnen Sie einen langsamen horizontalen Strich über die nutzbare Fläche und heben Sie dann ab.
4. Zeichnen Sie einen langsamen vertikalen Strich und heben Sie dann ab.
5. Wiederholen Sie jede fragwürdige Aktion allein in einer kürzeren Aufzeichnung.

Zeichnen Sie für jeden Tipp auf, ob ein neuer Kontakt erscheint, ob seine Position innerhalb der gemeldeten Achsengrenzen liegt und ob das abschließende Abheben den Kontakt beendet. Vergleichen Sie die Positionen über die fünf Punkte hinweg. Sie sollten ein wiederholbares räumliches Muster bilden, aber Rohachsen können in ihrer Richtung vom angezeigten Bild abweichen. Dokumentieren Sie, ob jede Rohachse bei jeder physischen Bewegung zunimmt oder abnimmt, und vergleichen Sie dies mit der beabsichtigten Ausrichtung des Projekts. Physisch oben links muss bei einer gedrehten oder gespiegelten Baugruppe nicht beiden Achsenminima entsprechen.

Suchen Sie für jeden Strich nach einer Abfolge von Positionsänderungen, die der Bewegung entsprechen. Zeichnen Sie plötzliche Sprünge, unerwartete Kontaktenden oder Werte auf, die wiederholt aufhören, einen Teil des beabsichtigten Bereichs abzudecken. Ein horizontaler physischer Strich kann bei einer gedrehten Baugruppe hauptsächlich die andere Rohachse ändern; diese Beobachtung ist ein nützlicher Hinweis, kein automatischer Defekt.

Wiederholen Sie dieselbe Bewegung, wenn etwas falsch erscheint. Notieren Sie, ob sich die Anomalie an derselben Stelle wiederholt oder unvorhersehbar auftritt. Beide Muster können die weitere Untersuchung leiten, aber keines allein identifiziert die fehlerhafte Komponente.

Eine erfolgreiche grundlegende Beobachtung ist vollständiges Drücken, Bewegen und Loslassen mit wiederholbarer Abdeckung. Sie belegt nicht die Produktionsgenauigkeit, Latenz, Umgebungsleistung oder Langzeitzuverlässigkeit. Diese erfordern anwendungsspezifische Abnahmekriterien und einen separaten Qualifizierungsplan.

5. Testen Sie mehrere Kontakte nur, wenn dies unterstützt wird

Fahren Sie nur fort, wenn die dokumentierte Gerätefähigkeit und die Ereignisschnittstelle den beabsichtigten Multi-Touch-Test unterstützen. Wenn nicht, dokumentieren Sie die Einschränkung, anstatt ein Einzelkontakt-Ergebnis als fehlgeschlagenen Zwei-Finger-Test zu interpretieren.

Platzieren Sie bei einem unterstützten Typ-B-Gerät einen Finger nahe der linken Seite und halten Sie ihn still. Platzieren Sie einen zweiten Finger nahe der rechten Seite. Bewegen Sie nur den zweiten Finger, heben Sie ihn ab, bewegen Sie dann den ersten und heben Sie ihn ab. Wiederholen Sie schließlich mit vertauschten Rollen.

Beginnen Sie die Aufzeichnung mit beiden abgehobenen Fingern und verfolgen Sie dann Kontaktidentitäten und beibehaltenen Slot-Zustand über die Frames hinweg. Die nützlichen Beobachtungen sind zwei unterscheidbare aktive Kontakte, Bewegung im Zusammenhang mit dem beabsichtigten Kontakt, Freigabe eines Kontakts, während der andere aktiv bleibt, und Freigabe des letzten Kontakts. Der ausgewählte Slot oder stationäre Koordinaten wiederholen sich möglicherweise nicht in jedem Frame.

Halten Sie die beiden Finger weit genug auseinander, um die beabsichtigten Aktionen klar zu machen. Dieser Test prüft, ob der gemeldete Lebenszyklus dem Verfahren folgt. Er ist keine Kontaktanzahl-Zertifizierung oder Mindestabstandsmessung.

Wenn die Rohsequenz mehrdeutig ist, wiederholen Sie nur den Übergang, der Zweifel verursacht hat. Eine kurze Aufzeichnung von “zweiter Finger runter, zweiter Finger hoch, erster Finger hoch” ist leichter zu überprüfen als eine lange Sitzung mit vielen unabhängigen Gesten.

6. Vergleichen Sie libinput mit denselben physischen Aktionen

Beenden evtest, und untersuchen Sie dann libinput:

sudo libinput list-devices

libinput list-devices zeigt von libinput erkannte Geräte, ihre Fähigkeiten und integrierte Standardwerte. Es meldet nicht die tatsächliche Desktop-Konfiguration.^[5] Finden Sie den bestätigten Ereignisknoten und untersuchen Sie seine gemeldete Touch-Fähigkeit. Verlassen Sie sich nicht auf ein festes Spaltenlayout der Ausgabe für automatisiertes Parsen.

libinput debug-events überwacht Ereignisse in einem separaten Kontext. Sein Verhalten kann vom Compositor oder der Anwendung abweichen.^[6] Wiederholen Sie den Mitteltipp, den horizontalen Strich und die abschließende Freigabe. Wiederholen Sie, falls unterstützt, die Zwei-Kontakt-Sequenz. Beenden Sie die Sitzung mit Strg+C.

Wenn rohe Touch-Daten kohärent sind, libinput den Knoten aber nicht wie erwartet erkennt, bewahren Sie beide Ausgaben auf. Die nächste Untersuchung betrifft Erkennung, Klassifizierung oder die getestete Userspace-Umgebung. Der Vergleich hat die Frage eingegrenzt; er hat nicht bewiesen, dass das Panel oder die Controller-Firmware defekt ist.

Wenn beide Werkzeuge kohärenten Touch zeigen, wechseln Sie zur tatsächlichen Anwendung. Ein separater libinput-Test kann die Display-Zuordnung, Rotation oder Ereignisverarbeitung der Anwendung durch den Compositor nicht zertifizieren.

7. Lokalisieren Sie die fehlerhafte Schicht, ohne eine Lösung zu raten

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 touchscreen module guide; 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.

Referenzen

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.