← 뉴스 및 인사이트로 돌아가기
지식9분 읽기

Linux USB 터치스크린 문제 해결: 실습 중심의 evtest 및 libinput 워크플로

읽기 전용 evtest 및 libinput 절차, 이벤트 해석, 재현 가능한 테스트 기록을 사용하여 임베디드 Linux에서 USB 터치스크린 입력 문제를 해결합니다.

Linux USB Touchscreen Troubleshooting: A Hands-On evtest and libinput Workflow

USB 터치스크린이 USB 장치 목록에 나타나더라도 애플리케이션은 여전히 사용 가능한 터치 입력을 받지 못할 수 있습니다. 실패한 계층을 찾으려면 장치 식별, 커널 이벤트 노드, 접촉 이벤트, libinput, 애플리케이션 순서로 경로를 테스트하십시오. 각 비교가 특정 질문에 답할 수 있도록 동일한 터치스크린과 테스트 동작을 일관되게 유지하십시오.

이 Linux USB 터치스크린 문제 해결 워크플로는 evdev 인터페이스를 노출하는 터치 컨트롤러를 다룹니다. 읽기 전용 진단 명령을 사용하며 반복 가능한 벤치 절차를 제안합니다. 작성 중에는 대상 터치스크린이 연결되지 않았습니다. 명령은 문서와 대조하여 확인되었으며, 이 절차는 완료된 하드웨어 검증이 아닙니다.

1. 환경을 기록하고 USB 장치를 찾습니다

가능하면 알려진 터치스크린 하나로 시작하십시오. 노트에서 디스플레이 연결과 터치 연결을 분리하십시오. 영상 이미지가 정상이라고 해서 USB 터치 컨트롤러가 열거되었음이 입증되는 것은 아닙니다.

Separate finished cables connect an enclosed touch display and a compact host on a workbench.
개념적 연결 맥락이며, 커넥터, 배선 및 전원 요구 사항은 실제 제품 문서를 사용하십시오.
uname -r

커널 릴리스와 사용 가능한 도구를 기록하십시오. 패키지 이름, 접근 권한 및 도구 버전은 배포판에 따라 다릅니다. 명령이 없는 경우 해당 테스트 부분을 수행하기 전에 배포판의 문서화된 절차를 통해 적절한 도구를 확보하십시오.

lsusb USB 장치를 나열합니다.[8] 그럴듯한 컨트롤러 항목을 하드웨어 문서 또는 기존 장치 기록과 대조하십시오. 제품 이름이 일반적일 수 있으므로 벤더 및 제품 식별자도 함께 보존하십시오. USB 열거만으로는 커널이 터치 이벤트 노드를 생성했거나 GUI가 이를 사용할 수 있음이 입증되지 않습니다.

꺼짐 /proc/bus/input/devices, 에서 후보 입력 장치와 해당 이벤트 핸들러를 찾으십시오. Linux는 다음과 같은 evdev 노드를 통해 커널 입력 이벤트를 사용자 공간에 노출합니다 /dev/input/event7.[1] 컨트롤러는 둘 이상의 입력 인터페이스를 노출할 수 있습니다. 이름에 “USB”가 포함되어 있다는 이유만으로 노드를 선택하지 마십시오.”

예상되는 USB ID가 없는 경우 먼저 해당 열거 문제를 해결하십시오. 연결 구성과 장치가 일관되게 나타나는지 여부를 기록하십시오. 이후의 이벤트 테스트는 식별된 입력 경로가 없는 장치를 진단할 수 없습니다.

2. 터치를 캡처하기 전에 이벤트 노드를 확인합니다

아래의 모든 명령에서, N 은 자리 표시자입니다. 사용 중인 컴퓨터에서 식별된 이벤트 번호로 바꾸십시오. 문자 N 를 그대로 입력하지 마십시오.

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

udevadm info 는 장치 데이터베이스에서 정보를 읽습니다. 사용 가능한 경우 USB 식별자, 일련번호 또는 장치 경로가 노드를 컨트롤러에 연결하는 데 도움이 됩니다.[7] 속성은 달라지거나 없을 수 있습니다. 재연결 후 이벤트 번호가 동일한 장치를 식별할 것이라고 가정하지 말고 출력을 캡처와 함께 보관하십시오.

evtest 는 장치 기능을 출력한 다음 이벤트를 모니터링합니다. 노드를 읽으려면 종종 상승된 권한이 필요합니다.[2] 테스트 시스템에 적절한 권한을 사용하십시오. 노드를 전 세계 쓰기 가능 액세스로 변경하지 마십시오. Ctrl+C 를 눌러 각 모니터링 세션을 종료하십시오.

모든 손가락을 든 상태로 시작하십시오. 한 손가락으로 중앙을 한 번 터치한 다음 드십시오. 이 동작이 후보 노드에서 이벤트를 생성하는지 확인하십시오. 절대 축 및 멀티터치 필드에 대한 기능을 읽으십시오. 관련 없는 컨트롤만 노출하는 노드는 필요한 터치 인터페이스가 아닙니다.

여러 노드가 여전히 그럴듯한 경우 한 세션을 종료하고 다음 후보를 검사하십시오. 각 노드를 해당 ID 및 관찰된 응답과 연결하는 메모를 유지하십시오. 이렇게 하면 잘못된 인터페이스의 무응답을 컨트롤러 고장으로 해석하는 것을 피할 수 있습니다.

를 추가하지 마십시오 --grab. 배타적 그랩은 입력을 받는 클라이언트를 변경하여 이후 애플리케이션 비교를 방해합니다.

3. 트레이스를 판단하기 전에 이벤트 어휘를 읽습니다

입력 보고는 상태 기반이므로 변경되지 않은 값은 다시 나타나지 않아도 됩니다. EV_ABS 는 절대 축 이벤트를 식별하고, SYN_REPORT 는 입력 프레임을 구분합니다. SYN_DROPPED 는 클라이언트 이벤트 큐의 오버플로를 나타냅니다.[3] 해당 마커가 포함된 캡처는 불완전합니다. 더 짧은 캡처를 반복하고 손실을 보고하십시오. 불완전한 시퀀스를 사용하여 릴리스 누락이나 하드웨어 결함을 입증하지 마십시오.

장치에 대해 출력된 축 한계를 읽으십시오. 이는 원시 입력 단위이며 반드시 LCD 픽셀은 아닙니다. 원시 X 최대값에 가까운 값이 애플리케이션이 포인터를 수치적으로 동일한 픽셀 좌표에 배치해야 함을 의미하지는 않습니다.

위치 변경뿐만 아니라 접촉 수명 주기를 찾으십시오. 정확한 필드는 기능에 따라 다릅니다. 모든 장치가 압력을 보고하거나, 다중 접촉을 지원하거나, 동일한 프로토콜을 사용한다고 가정하지 마십시오.

type B 멀티터치 프로토콜을 사용하는 장치의 경우 슬롯은 상태를 유지합니다. 음수가 아닌 ABS_MT_TRACKING_ID 는 접촉을 식별하고,; -1 는 해당 릴리스를 표시합니다. ABS_MT_POSITION_X 그리고 ABS_MT_POSITION_Y 위치를 설명하십시오. ABS_MT_SLOT 선택된 슬롯이 변경되지 않은 경우 생략될 수 있습니다.[4]

결과적으로, 정지한 손가락은 반복적인 좌표를 생성할 필요가 없습니다. 움직이는 손가락만 나열한 트레이스도 두 개의 활성 접점을 설명할 수 있습니다. 다른 손가락을 누락이라고 판단하기 전에 유지된 상태를 재구성하십시오.

4. 5점 및 2획 원시 입력 테스트를 실행하십시오

유지하십시오 evtest 확인된 노드에서 실행하십시오. 다음 제안된 프로토콜을 사용하여 실행 간 캡처를 비교 가능하게 만드십시오. 이는 기본적인 커버리지와 연속성을 확인하며, 보편적인 정확도 임계값을 설정하지는 않습니다.

  1. 중앙을 한 번 탭하고, 잠시 누른 후 완전히 들어 올리십시오.
  2. 좌상단, 우상단, 우하단, 좌하단 영역에서 반복하십시오. 각 지점이 베젤이 아닌 활성 터치 영역 내부에 명확히 위치하도록 하십시오.
  3. 사용 가능한 영역을 가로질러 느린 수평 획을 한 번 그린 후 들어 올리십시오.
  4. 느린 수직 획을 한 번 그린 후 들어 올리십시오.
  5. 의심스러운 동작이 있으면 해당 동작만 짧은 캡처로 반복하십시오.

각 탭에 대해 새 접점이 나타나는지, 그 위치가 보고된 축 한계 내에 있는지, 최종 들어 올림이 접점을 종료시키는지 기록하십시오. 다섯 지점의 위치를 비교하십시오. 이들은 반복 가능한 공간 패턴을 형성해야 하지만, 원시 축은 표시된 이미지와 방향이 다를 수 있습니다. 각 물리적 움직임에 따라 각 원시 축이 증가하는지 감소하는지 문서화한 후, 이를 프로젝트의 의도된 방향과 비교하십시오. 회전되거나 미러링된 어셈블리에서 물리적 좌상단이 반드시 두 축의 최솟값에 대응하지는 않습니다.

각 획에 대해 움직임에 대응하는 일련의 위치 변화를 찾으십시오. 갑작스러운 점프, 예상치 못한 접점 종료, 또는 의도된 영역의 일부를 반복적으로 커버하지 못하는 값을 기록하십시오. 회전된 어셈블리에서 물리적 수평 획은 주로 다른 원시 축을 변경할 수 있으며, 이 관찰은 유용한 증거이지 자동적인 결함은 아닙니다.

문제가 있어 보이면 동일한 동작을 반복하십시오. 이상 현상이 같은 위치에서 반복되는지 또는 예측 불가능하게 발생하는지 기록하십시오. 어느 패턴이든 추가 조사를 안내할 수 있지만, 어느 것 하나만으로 실패한 구성 요소를 식별할 수는 없습니다.

성공적인 기본 관찰은 반복 가능한 커버리지를 갖춘 완전한 누름, 움직임, 해제입니다. 이는 생산 정확도, 지연 시간, 환경 성능 또는 장기 신뢰성을 입증하지 않습니다. 이러한 것들은 애플리케이션별 승인 기준과 별도의 검증 계획이 필요합니다.

5. 지원되는 경우에만 다중 접점을 테스트하십시오

문서화된 장치 기능과 이벤트 인터페이스가 의도된 멀티터치 테스트를 지원하는 경우에만 진행하십시오. 지원하지 않는 경우, 단일 접점 결과를 실패한 두 손가락 테스트로 해석하지 말고 한계를 기록하십시오.

Two fingertips touch well-separated areas of a supported conceptual touch panel.
예시적인 두 접점 테스트 맥락에 불과하며, 선택된 하드웨어에 대해 멀티터치 기능이 확인되어야 합니다.

지원되는 type B 장치의 경우, 한 손가락을 왼쪽 근처에 놓고 정지 상태로 유지하십시오. 두 번째 손가락을 오른쪽 근처에 놓으십시오. 두 번째 손가락만 움직이고, 들어 올린 후, 첫 번째 손가락을 움직이고 들어 올리십시오. 마지막으로 역할을 바꾸어 반복하십시오.

두 손가락을 모두 들어 올린 상태에서 캡처를 시작한 후, 프레임 전반에 걸쳐 접점 ID와 유지된 슬롯 상태를 추적하십시오. 유용한 관찰 사항은 두 개의 구별 가능한 활성 접점, 의도된 접점과 연관된 움직임, 한 접점이 다른 접점이 활성 상태인 동안 해제되는 것, 그리고 마지막 접점의 해제입니다. 선택된 슬롯이나 정지 좌표는 각 프레임에서 반복되지 않을 수 있습니다.

의도된 동작을 명확하게 하기 위해 두 손가락을 충분히 멀리 떨어뜨려 유지하십시오. 이 테스트는 보고된 라이프사이클이 절차를 따르는지 확인합니다. 이는 접점 수 인증이나 최소 간격 측정이 아닙니다.

원시 시퀀스가 모호한 경우, 의문을 야기한 전환만 반복하십시오. “두 번째 손가락 누름, 두 번째 손가락 들어 올림, 첫 번째 손가락 들어 올림”의 짧은 캡처는 많은 무관한 제스처를 포함하는 긴 세션보다 검토하기 쉽습니다.

6. 동일한 물리적 동작으로 libinput을 비교하십시오

종료하십시오 evtest, 그런 다음 libinput을 검사하십시오:

sudo libinput list-devices

libinput list-devices 는 libinput이 인식하는 장치, 해당 기능 및 내장 기본값을 표시합니다. 실제 데스크톱 구성을 보고하지는 않습니다.[5] 확인된 이벤트 노드를 찾아 보고된 터치 기능을 검사하십시오. 자동화된 파싱을 위해 고정된 출력 열 레이아웃에 의존하지 마십시오.

libinput debug-events 는 별도의 컨텍스트에서 이벤트를 모니터링합니다. 그 동작은 컴포지터나 애플리케이션과 다를 수 있습니다.[6] 중앙 탭, 수평 획, 최종 해제를 반복하십시오. 지원되는 경우 두 접점 시퀀스를 반복하십시오. 다음으로 세션을 종료하십시오 Ctrl+C.

원시 터치가 일관되지만 libinput이 노드를 예상대로 인식하지 못하는 경우, 두 출력을 모두 보존하십시오. 다음 조사는 인식, 분류 또는 테스트된 사용자 공간 환경에 관한 것입니다. 비교는 질문의 범위를 좁혔을 뿐, 패널이나 컨트롤러 펌웨어가 결함이 있다는 것을 입증한 것은 아닙니다.

두 도구 모두 일관된 터치를 보여주는 경우, 실제 애플리케이션으로 이동하십시오. 별도의 libinput 테스트는 컴포지터의 디스플레이 연관성, 회전 또는 애플리케이션 이벤트 처리를 인증할 수 없습니다.

7. 수정을 추측하지 말고 실패한 계층을 찾으십시오

관찰 이것이 좁히는 것 수집할 다음 증거
USB 장치 존재; 예상 이벤트 노드 미확인 열거는 확인되지만 입력 경로는 여전히 식별되지 않음. 컨트롤러 ID, 입력 장치 목록 및 드라이버 바인딩 정보.
확인된 노드가 열리지만 터치 이벤트가 표시되지 않음 캡처가 조용함; 원인은 여전히 미해결. 노드 ID, 접근 권한, 바인딩 및 다른 클라이언트에 의한 독점 접근 가능성을 재확인하십시오.
원시 라이프사이클 또는 커버리지가 반복적으로 잘못 보임 이상 현상이 애플리케이션 매핑 이전에 나타남. 기능, 물리적 동작 및 연결 조건을 포함한 짧은 반복 캡처.
원시 이벤트는 일관되나 libinput이 다름 차이는 테스트된 사용자 공간 해석 계층에서 나타남. 두 도구의 출력, 버전 및 장치 분류.
Tools look coherent; application position or release differs The actual GUI path needs inspection. Compositor or toolkit mapping, output association, rotation, and application behavior.

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.

An engineer touches a large tile on a portrait industrial HMI beside a separate host and monitor.
Conceptual application context; the image establishes no operating-system compatibility, mapping accuracy or completed validation.

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 터치스크린 모듈 가이드는; 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.

이 기사를 공유하세요.

팀이나 네트워크에 전달하세요.

링크드인 Facebook X 왓츠앱

RJY Display 발행.

모든 기사로 돌아가기

계속 탐색하기

RJY의 더 많은 콘텐츠.