Не простые проблемы простого устройства, ёмкостной тачскрин на ft5406.
Чистил однажды облако и нашел свои заметки по проблеме сенсорного экрана с ёмкостным тачскрином на ft5406. Вот так и появилась эта статья, а вдруг кто еще наткнётся на подобное во время разработки…
Наткнулся как-то на проблему с ёмкостным тачскрином на ft5406, сенсорный экран в один прекрасный момент просто подвисал и отказывался дальше работать. Ну, а теперь поподробней об этом.
Железо: marsboard sun7i A20.
ПО: uboot 2017, kernel 4.10, LUbuntu 16.04.
Суть проблемы.
Сенсорный экран по окончании загрузки, если во время загрузки его не трогать, отказывался работать. Т.е. не реагировал на касания, при этом такой же экран на этом же железе вполне сносно отрабатывал.
Чтоб его оживить, приходилось перезагружать его виртуальный указатель через Xinput, система ввода Xorg, в консоли.
т.к. touchscreen показывал такую странную реакцию на xinput, то покопавшись в его недрах (xinput), были найдены два теста xinput test – тест виртуального указателя и xinput test-xi2 – тоже такой же тест, но по протоколу XI 2.0 (The X Input Extension 2.x), просто более адаптирован под мультитач. Можно почитать про него тут (https://www.x.org/wiki/Development/Documentation/Multitouch/). В общем, если первый тест не показал никакой реакции на сенсорный экран, то второй – исправно показал перемещение координат.
Опускаемся на уровень ниже, тест работы модуля ядра evt-ft5x06 (драйвер для ft5406) evtest, немножко нервов и ожидания, показал интересные результаты. Периодически, по любой из пяти точек, поддерживаемых контроллером сенсорного экрана, проскакивает координата вне предела панели. Эта координата драйвером ввода xserver-xorg-input-evdev воспринимается как нажатие, а событие отжатия (есть такое на ft5406) не приходит и до тех пор, пока не тыкнешь в экран количеством пальцев соответствующим номеру проскочившей координаты (хорошо что их пять и хватало пятерни) сенсорная панель будет висеть, думая что событие нажатия еще не окончено.
Проба установки других драйверов экрана, таких как:
-
xserver-xorg-input-libinput
-
xserver-xorg-input-mtrack
И прописывание их в /usr/share/X11/xorg.conf.d ситуацию не изменили, если libinput полностью повторил оригинальный драйвер, то mtrack хоть и избавил от проблемы, но то, что он ориентирован только на touchpad,поставило на нем крест. Т.к. сенсорный экран становился, как большой touchpad с полным несоответствием координат, и никакая калибровка при загрузке не помогла.
т.к. вышеуказанное показало свою несостоятельность в режиме multitouch, а протокол XI 2.0 еще находится в разарботке, то решение было найдено на уровне модулей ядра.
Решено было запретить прерывания всех точек, кроме первой, а так как это для уровня devicetree (файл devicetree используется для настройки kernell при загрузке, он стал основным методом конфигурирвания после версии ядра 3.11) не реализовано, то делалось это прямо в модуле и свелось все практически к запятой…
В исходниках ядра по адресу /drivers/input/touchscreen/ находим файл модуля edt-ft5x06.c и в самом конце в структуре:
static const struct edt_i2c_chip_data edt_ft5x06_data = {
...
.max_support_points = 5,
...
}; Исправляем 5 на 1. И становится у нас сенсорная панель с одновременной обработкой только одной координаты.
Дальнейшая сборка и запуск ядра показали работоспособность сенсорной панели. Ошибки, конечно, проскакивают и по первой координате, но лишний раз ткнуть в экран одним пальцем куда проще чем пятернёй одновременно.
Конечно, можно еще указать обновление координат при сбое в обработчике прерывания
static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
, но это уже не принципально.
Вместо заключения.
В связке контроллер панели и сама сенсорная панель так и не удалось выяснить кто виноват. Но основные подозрения падали на саму панель, т.к. через некоторое время после работы (считай прогрева) левые координаты переставали идти.
