Устранение неполадок с USB-сенсорным экраном в Linux: практическое руководство по работе с evtest и libinput

USB-сенсорный экран может отображаться в списке USB-устройств, при этом приложение всё равно не получает пригодных данных сенсорного ввода. Чтобы определить отказавший уровень, проверяйте путь по порядку: идентификация устройства, узел событий ядра, события контакта, libinput и приложение. Используйте один и тот же сенсорный экран и одни и те же тестовые движения на протяжении всей проверки, чтобы каждое сравнение отвечало на конкретный вопрос.

Данный рабочий процесс устранения неисправностей USB-сенсорного экрана в Linux охватывает сенсорные контроллеры, предоставляющие интерфейс evdev. Он использует диагностические команды только для чтения и предлагает воспроизводимую процедуру стендовой проверки. При подготовке материала целевой сенсорный экран не подключался; команды сверялись с документацией, и процедура не является завершённой квалификацией оборудования.

1. Зафиксируйте окружение и найдите USB-устройство

По возможности начните с одного известного сенсорного экрана. В своих записях отделите подключение дисплея от подключения сенсорной панели. Работающее видеоизображение не подтверждает, что USB-контроллер сенсорной панели прошёл перечисление.

uname -r

Зафиксируйте версию ядра и доступные инструменты. Имена пакетов, права доступа и версии инструментов различаются в зависимости от дистрибутива. Если команда отсутствует, получите соответствующий инструмент через документированный процесс вашего дистрибутива, прежде чем выполнять эту часть проверки.

lsusb выводит список USB-устройств.^[8] Сопоставьте правдоподобную запись контроллера с документацией на оборудование или существующей записью устройства. Название продукта может быть обобщённым, поэтому сохраняйте также идентификаторы производителя и продукта. Одно лишь перечисление USB не доказывает, что ядро создало узел событий сенсорного ввода или что графический интерфейс может его использовать.

В /proc/bus/input/devices, найдите подходящее устройство ввода и его обработчик событий. Linux предоставляет события ввода ядра в пользовательское пространство через узлы evdev, такие как /dev/input/event7.^[1] Контроллер может предоставлять более одного интерфейса ввода. Не выбирайте узел только потому, что его имя содержит “USB”.”

Если ожидаемая идентификация USB отсутствует, сначала решите этот вопрос перечисления. Зафиксируйте схему подключения и то, появляется ли устройство стабильно. Последующие тесты событий не могут диагностировать устройство, у которого не определён путь ввода.

2. Подтвердите узел событий перед захватом сенсорного ввода

Во всех приведённых ниже командах, N является заполнителем. Замените его на номер события, определённый на вашей машине; не вводите букву N буквально.

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

udevadm info считывает информацию из базы данных устройств. Если доступны, идентификаторы USB, серийный номер или путь устройства помогают связать узел с контроллером.^[7] Свойства могут различаться или отсутствовать. Сохраняйте вывод вместе с захватом, а не предполагайте, что номер события будет идентифицировать то же устройство после переподключения.

evtest выводит возможности устройства, а затем отслеживает события. Для чтения узла часто требуются повышенные права.^[2] Используйте права, соответствующие вашей тестовой системе. Не изменяйте узел на доступ, разрешённый для записи всем. Нажмите Ctrl+C чтобы завершить каждый сеанс мониторинга.

Начните со всех поднятых пальцев. Один раз коснитесь центра одним пальцем, затем поднимите его. Убедитесь, что это действие порождает события на проверяемом узле. Прочитайте возможности для абсолютных осей и любых полей мультитач. Узел, предоставляющий только несвязанные элементы управления, не является нужным интерфейсом сенсорного ввода.

Если несколько узлов остаются правдоподобными, завершите один сеанс и проверьте следующий кандидат. Ведите запись, связывающую каждый узел с его идентификацией и наблюдаемой реакцией. Это позволяет избежать интерпретации молчания неверного интерфейса как отказа контроллера.

Не добавляйте --grab. Эксклюзивный захват изменяет то, какие клиенты получают ввод, и помешал бы последующему сравнению с приложением.

3. Изучите словарь событий перед оценкой трассировки

Отчёты ввода являются stateful: неизменённые значения могут не появляться повторно. EV_ABS обозначает события абсолютных осей, а SYN_REPORT разделяет кадры ввода. SYN_DROPPED указывает на переполнение очереди событий клиента.^[3] Захват, содержащий этот маркер, является неполным; повторите более короткий захват и сообщите о потере. Не используйте неполную последовательность для доказательства отсутствующего отпускания или аппаратной неисправности.

Прочитайте напечатанные для устройства пределы осей. Это необработанные единицы ввода, не обязательно пиксели ЖК-дисплея. Значение, близкое к необработанному максимуму X, не означает, что приложение должно разместить указатель в численно идентичной пиксельной координате.

Ищите как жизненный цикл контакта, так и изменения положения. Точные поля зависят от возможностей. Не предполагайте, что каждое устройство сообщает давление, поддерживает несколько контактов или использует один и тот же протокол.

Для устройства, использующего протокол мультитач типа B, слоты сохраняют состояние. Неотрицательный ABS_MT_TRACKING_ID идентифицирует контакт; -1 обозначает его отпускание. ABS_MT_POSITION_X и ABS_MT_POSITION_Y описывают его положение. ABS_MT_SLOT может отсутствовать, если выбранный слот не изменился.^[4]

Следовательно, неподвижный палец не должен генерировать повторяющиеся координаты. Трасса, в которой перечислен только движущийся палец, всё ещё может описывать два активных контакта. Восстановите сохранённое состояние, прежде чем объявлять другой палец отсутствующим.

4. Выполните тест необработанного ввода с пятью точками и двумя штрихами

Оставьте evtest работу на подтверждённом узле. Используйте следующий предлагаемый протокол, чтобы сделать записи сопоставимыми между запусками. Он проверяет базовое покрытие и непрерывность; он не устанавливает универсальный порог точности.

1. Коснитесь центра один раз, кратко удержите и полностью отпустите.
2. Повторите в верхней левой, верхней правой, нижней правой и нижней левой областях. Каждая точка должна находиться явно внутри активной области касания, а не на рамке.
3. Проведите один медленный горизонтальный штрих по рабочей области, затем отпустите.
4. Проведите один медленный вертикальный штрих, затем отпустите.
5. Повторите любое сомнительное действие отдельно в более короткой записи.

Для каждого касания зафиксируйте, появляется ли новый контакт, находится ли его позиция в пределах заявленных границ осей и завершает ли контакт финальное отпускание. Сравните позиции по пяти точкам. Они должны образовывать воспроизводимый пространственный шаблон, но направления необработанных осей могут отличаться от отображаемого изображения. Задокументируйте, увеличивается или уменьшается каждая необработанная ось при каждом физическом перемещении, затем сравните это с предполагаемой ориентацией проекта. Физический верхний левый угол не обязательно должен соответствовать обоим минимумам осей на повёрнутой или зеркальной сборке.

Для каждого штриха ищите последовательность изменений позиции, соответствующую перемещению. Зафиксируйте внезапные скачки, неожиданные завершения контакта или значения, которые повторно перестают покрывать часть предполагаемой области. Горизонтальный физический штрих может преимущественно изменять другую необработанную ось на повёрнутой сборке; это наблюдение является полезным свидетельством, а не автоматическим дефектом.

Повторите то же движение, если что-то выглядит неправильно. Отметьте, повторяется ли аномалия в том же месте или возникает непредсказуемо. Любой из этих паттернов может направить дальнейшее исследование, но ни один из них сам по себе не идентифицирует отказавший компонент.

Успешное базовое наблюдение — это полное нажатие, перемещение и отпускание с воспроизводимым покрытием. Оно не устанавливает производственную точность, задержку, экологическую производительность или долгосрочную надёжность. Для этого требуются критерии приёмки, специфичные для приложения, и отдельный план квалификации.

5. Тестируйте множественные контакты только при наличии поддержки

Продолжайте только если задокументированные возможности устройства и интерфейс событий поддерживают предполагаемый тест мультитач. Если они не поддерживают, зафиксируйте ограничение, а не интерпретируйте результат с одним контактом как неудачный тест двумя пальцами.

Для поддерживаемого устройства типа B поместите один палец near левой стороны и удерживайте его неподвижно. Поместите второй палец near правой стороны. Перемещайте только второй палец, отпустите его, затем переместите и отпустите первый. Наконец, повторите с обратными ролями.

Начните запись с обоими поднятыми пальцами, затем отслеживайте идентичности контактов и сохранённое состояние слотов между кадрами. Полезные наблюдения — это два различимых активных контакта, перемещение, связанное с предполагаемым контактом, отпускание одного контакта при сохранении активности другого и отпускание последнего контакта. Выбранный слот или неподвижные координаты могут не повторяться в каждом кадре.

Держите два пальца достаточно далеко друг от друга, чтобы предполагаемые действия были ясны. Этот тест проверяет, следует ли сообщаемый жизненный цикл процедуре. Это не сертификация количества контактов и не измерение минимального расстояния.

Если необработанная последовательность неоднозначна, повторите только тот переход, который вызвал сомнение. Короткая запись “второй палец вниз, второй палец вверх, первый палец вверх” легче для анализа, чем длинная сессия, содержащая множество несвязанных жестов.

6. Сравните libinput с теми же физическими действиями

Завершите evtest, затем проверьте libinput:

sudo libinput list-devices

libinput list-devices показывает устройства, распознанные libinput, их возможности и встроенные значения по умолчанию. Он не сообщает фактическую конфигурацию рабочего стола.^[5] Найдите подтверждённый узел событий и проверьте его заявленную возможность касания. Не полагайтесь на фиксированный макет выходных столбцов для автоматического разбора.

libinput debug-events отслеживает события в отдельном контексте. Его поведение может отличаться от композитора или приложения.^[6] Повторите касание центра, горизонтальный штрих и финальное отпускание. Если поддерживается, повторите последовательность с двумя контактами. Завершите сессию с Ctrl+C.

Если необработанное касание согласовано, но libinput не распознаёт узел, как ожидалось, сохраните оба вывода. Следующее исследование касается распознавания, классификации или тестируемой среды пользовательского пространства. Сравнение сузило вопрос; оно не доказало, что панель или прошивка контроллера неисправны.

Если оба инструмента показывают согласованное касание, переходите к фактическому приложению. Отдельный тест libinput не может подтвердить связь дисплея композитора, поворот или обработку событий приложения.

7. Локализуйте отказавший слой без предположений об исправлении

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.

Ссылки

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.