해결책
USB는 PC의 케이블 동물원을 끝낼 것으로 기대되었지만, 인간 인터페이스 장치에는 또 다른 문제가 있었다. 모든 마우스, 키보드, 태블릿, 게임 컨트롤러가 서로 다른 버튼, 축, 휠, LED 조합을 노출할 수 있었다. 어리석은 답은 주변기기 제품군마다 드라이버를 두는 것이었다.
HID의 영리한 수는 리포트 디스크립터였다. 장치 자체가 어떤 리포트를 주고받을 수 있는지, 각 필드가 무엇을 의미하는지 기술하는 압축된 바이트코드를 보낸다. 이 클래스 정의는 명시적으로 압축적이고, 확장 가능하며, 자기 기술적(self-describing)인 것을 목표로 했다.
그 덕분에 새로운 것의 비용이 저렴해졌다. 호스트는 하나의 HID 클래스 드라이버로 많은 장치를 사용할 수 있었고, 제조사는 모든 운영체제 벤더를 먼저 설득해 모델별 새 드라이버를 배포하게 하지 않고도 컨트롤을 추가할 수 있었다.
이룬 것
장치가 자신의 컨트롤을 기술하게 하라
왜 통했는가
디스크립터는 장치별 지식을 호스트 소프트웨어에서 주변기기로 옮겼다.
알 수 없는 필드는 건너뛸 수 있었으므로, 이 형식은 미래의 장치를 견딜 수 있었다.
용도 테이블(usage table)은 물리적 설계를 고정하지 않고도 컨트롤에 공통된 의미를 부여했다.
하드웨어의 다양성이 끝이 없을 때는 모든 제품 형태를 표준화하기보다 기술 언어를 표준화하라. 범용 파서는 드라이버 카탈로그가 흡수할 수 없는 변화를 흡수할 수 있다.
그 후
HID는 USB 자체를 벗어났다. 리눅스 문서는 HID가 이제 USB, I2C, 블루투스 전송 계층에서 작동한다고 언급한다. 같은 발상은 특이한 키보드, 포인팅 장치, 컨트롤러가 열거(enumerate)되는 즉시 흔히 사용 가능해지는 이유를 여전히 설명해 준다.
근거 확인하기
출처
- Device Class Definition for HID 1.11 USB Implementers Forum · usb.org
- Introduction to HID report descriptors The Linux Kernel documentation · kernel.org