← Documents Documentation/hid/hidraw.rst GitHub 원문 ↗

Linux 6.18.37 · HID

HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices

Parser를 거치지 않는 raw HID report read·write와 descriptor·report ioctl API를 설명합니다.

Source pathDocumentation/hid/hidraw.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

hidraw.rst:1-180

Hidraw는 USB·Bluetooth HID report를 parser 검증 없이 그대로 주고받는 interface입니다. Custom·비준수 device userspace driver가 raw stream과 control report를 직접 다룰 수 있습니다.

문서 위치
항목
SourceDocumentation/hid/hidraw.rst
분량180 source lines
Node/dev/hidrawN
APIread · write · ioctl

Source와 핵심 범위입니다.

핵심 흐름
libudev로 node 찾기Descriptor·identity 조회Raw report read/writeFeature·input·output control request

이 문서가 설명하는 작업 순서입니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ================================================================
2 HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices
3 ================================================================
4
5 The hidraw driver provides a raw interface to USB and Bluetooth Human
6 Interface Devices (HIDs). It differs from hiddev in that reports sent and
7 received are not parsed by the HID parser, but are sent to and received from
8 the device unmodified.
9
10 Hidraw should be used if the userspace application knows exactly how to
11 communicate with the hardware device, and is able to construct the HID
12 reports manually. This is often the case when making userspace drivers for
13 custom HID devices.
14
15 Hidraw is also useful for communicating with non-conformant HID devices
16 which send and receive data in a way that is inconsistent with their report
17 descriptors. Because hiddev parses reports which are sent and received
18 through it, checking them against the device's report descriptor, such
19 communication with these non-conformant devices is impossible using hiddev.
20 Hidraw is the only alternative, short of writing a custom kernel driver, for
21 these non-conformant devices.
22
23 A benefit of hidraw is that its use by userspace applications is independent
24 of the underlying hardware type. Currently, hidraw is implemented for USB
25 and Bluetooth. In the future, as new hardware bus types are developed which
26 use the HID specification, hidraw will be expanded to add support for these
27 new bus types.
28
29 Hidraw uses a dynamic major number, meaning that udev should be relied on to
30 create hidraw device nodes. Udev will typically create the device nodes
31 directly under /dev (eg: /dev/hidraw0). As this location is distribution-
32 and udev rule-dependent, applications should use libudev to locate hidraw
33 devices attached to the system. There is a tutorial on libudev with a
34 working example at::
35
36 http://www.signal11.us/oss/udev/
37 https://web.archive.org/web/2019*/www.signal11.us
38
39 The HIDRAW API
40 ---------------
41
42 read()
43 -------
44 read() will read a queued report received from the HID device. On USB
45 devices, the reports read using read() are the reports sent from the device
46 on the INTERRUPT IN endpoint. By default, read() will block until there is
47 a report available to be read. read() can be made non-blocking, by passing
48 the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
49 fcntl().
50
51 On a device which uses numbered reports, the first byte of the returned data
52 will be the report number; the report data follows, beginning in the second
53 byte. For devices which do not use numbered reports, the report data
54 will begin at the first byte.
55
56 write()
57 -------
58 The write() function will write a report to the device. For USB devices, if
59 the device has an INTERRUPT OUT endpoint, the report will be sent on that
60 endpoint. If it does not, the report will be sent over the control endpoint,
61 using a SET_REPORT transfer.
62
63 The first byte of the buffer passed to write() should be set to the report
64 number. If the device does not use numbered reports, the first byte should
65 be set to 0. The report data itself should begin at the second byte.
66
67 ioctl()
68 -------
69 Hidraw supports the following ioctls:
70
71 HIDIOCGRDESCSIZE:
72 Get Report Descriptor Size
73
74 This ioctl will get the size of the device's report descriptor.
75
76 HIDIOCGRDESC:
77 Get Report Descriptor
78
79 This ioctl returns the device's report descriptor using a
80 hidraw_report_descriptor struct. Make sure to set the size field of the
81 hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE.
82
83 HIDIOCGRAWINFO:
84 Get Raw Info
85
86 This ioctl will return a hidraw_devinfo struct containing the bus type, the
87 vendor ID (VID), and product ID (PID) of the device. The bus type can be one
88 of::
89
90 - BUS_USB
91 - BUS_HIL
92 - BUS_BLUETOOTH
93 - BUS_VIRTUAL
94
95 which are defined in uapi/linux/input.h.
96
97 HIDIOCGRAWNAME(len):
98 Get Raw Name
99
100 This ioctl returns a string containing the vendor and product strings of
101 the device. The returned string is Unicode, UTF-8 encoded.
102
103 HIDIOCGRAWPHYS(len):
104 Get Physical Address
105
106 This ioctl returns a string representing the physical address of the device.
107 For USB devices, the string contains the physical path to the device (the
108 USB controller, hubs, ports, etc). For Bluetooth devices, the string
109 contains the hardware (MAC) address of the device.
110
111 HIDIOCSFEATURE(len):
112 Send a Feature Report
113
114 This ioctl will send a feature report to the device. Per the HID
115 specification, feature reports are always sent using the control endpoint.
116 Set the first byte of the supplied buffer to the report number. For devices
117 which do not use numbered reports, set the first byte to 0. The report data
118 begins in the second byte. Make sure to set len accordingly, to one more
119 than the length of the report (to account for the report number).
120
121 HIDIOCGFEATURE(len):
122 Get a Feature Report
123
124 This ioctl will request a feature report from the device using the control
125 endpoint. The first byte of the supplied buffer should be set to the report
126 number of the requested report. For devices which do not use numbered
127 reports, set the first byte to 0. The returned report buffer will contain the
128 report number in the first byte, followed by the report data read from the
129 device. For devices which do not use numbered reports, the report data will
130 begin at the first byte of the returned buffer.
131
132 HIDIOCSINPUT(len):
133 Send an Input Report
134
135 This ioctl will send an input report to the device, using the control endpoint.
136 In most cases, setting an input HID report on a device is meaningless and has
137 no effect, but some devices may choose to use this to set or reset an initial
138 state of a report. The format of the buffer issued with this report is identical
139 to that of HIDIOCSFEATURE.
140
141 HIDIOCGINPUT(len):
142 Get an Input Report
143
144 This ioctl will request an input report from the device using the control
145 endpoint. This is slower on most devices where a dedicated In endpoint exists
146 for regular input reports, but allows the host to request the value of a
147 specific report number. Typically, this is used to request the initial states of
148 an input report of a device, before an application listens for normal reports via
149 the regular device read() interface. The format of the buffer issued with this report
150 is identical to that of HIDIOCGFEATURE.
151
152 HIDIOCSOUTPUT(len):
153 Send an Output Report
154
155 This ioctl will send an output report to the device, using the control endpoint.
156 This is slower on most devices where a dedicated Out endpoint exists for regular
157 output reports, but is added for completeness. Typically, this is used to set
158 the initial states of an output report of a device, before an application sends
159 updates via the regular device write() interface. The format of the buffer issued
160 with this report is identical to that of HIDIOCSFEATURE.
161
162 HIDIOCGOUTPUT(len):
163 Get an Output Report
164
165 This ioctl will request an output report from the device using the control
166 endpoint. Typically, this is used to retrieve the initial state of
167 an output report of a device, before an application updates it as necessary either
168 via a HIDIOCSOUTPUT request, or the regular device write() interface. The format
169 of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
170
171 Example
172 -------
173 In samples/, find hid-example.c, which shows examples of read(), write(),
174 and all the ioctls for hidraw. The code may be used by anyone for any
175 purpose, and can serve as a starting point for developing applications using
176 hidraw.
177
178 Document by:
179
180 Alan Ott <[email protected]>, Signal 11 Software
181

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

수정되지 않은 raw HID 접근

1-38

Hidraw driver는 USB와 Bluetooth HID에 raw interface를 제공합니다. 송수신 report를 HID parser가 해석하지 않고 device에 보낸 그대로, device에서 받은 그대로 전달한다는 점이 hiddev와 다릅니다.

Userspace application이 hardware device의 통신 방법을 정확히 알고 HID report를 직접 구성할 수 있을 때 hidraw를 사용해야 합니다. Custom HID device의 userspace driver를 만들 때 흔한 방식입니다.

Hidraw는 실제 송수신 data가 report descriptor와 일치하지 않는 비준수 HID device와 통신할 때도 유용합니다. Hiddev는 report를 parse하고 descriptor와 검사하므로 이런 device와 통신할 수 없습니다.

Custom kernel driver를 작성하지 않는다면 hidraw가 비준수 device를 위한 유일한 대안입니다.

Hidraw userspace API는 underlying hardware type과 독립적입니다. 현재 USB와 Bluetooth에 구현되어 있으며 HID 명세를 사용하는 새 bus가 생기면 지원 범위를 확장할 수 있습니다.

Hidraw는 dynamic major number를 사용하므로 device node 생성은 udev에 맡겨야 합니다. Udev는 보통 `/dev/hidraw0`처럼 `/dev` 바로 아래에 node를 만듭니다.

위치는 distribution과 udev rule에 따라 달라지므로 application은 libudev로 system에 연결된 hidraw device를 찾아야 합니다. 원문은 Signal 11의 libudev tutorial과 web archive link를 제공합니다.

hidraw 사용 조건
상황hidraw 역할
Custom userspace driverReport를 application이 직접 구성
Descriptor 불일치 device검사 없이 raw byte 송수신
Transport 독립 applicationUSB·Bluetooth에 같은 API
Device discoveryDynamic major 대신 libudev 사용

Parser를 우회하는 이유와 범위를 정리했습니다.

Hidraw device discovery
Kernel이 hidraw device 등록udev가 dynamic major의 node 생성Distribution rule에 따라 path 결정Application이 libudev로 HID 속성 검색찾은 /dev/hidrawN node open

고정 path를 가정하지 않고 node를 찾습니다.

================================================================
HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices
================================================================

The hidraw driver provides a raw interface to USB and Bluetooth Human
Interface Devices (HIDs).  It differs from hiddev in that reports sent and
received are not parsed by the HID parser, but are sent to and received from
the device unmodified.

Hidraw should be used if the userspace application knows exactly how to
communicate with the hardware device, and is able to construct the HID
reports manually.  This is often the case when making userspace drivers for
custom HID devices.

Hidraw is also useful for communicating with non-conformant HID devices
which send and receive data in a way that is inconsistent with their report
descriptors.  Because hiddev parses reports which are sent and received
through it, checking them against the device's report descriptor, such
communication with these non-conformant devices is impossible using hiddev.
Hidraw is the only alternative, short of writing a custom kernel driver, for
these non-conformant devices.

A benefit of hidraw is that its use by userspace applications is independent
of the underlying hardware type.  Currently, hidraw is implemented for USB
and Bluetooth.  In the future, as new hardware bus types are developed which
use the HID specification, hidraw will be expanded to add support for these
new bus types.

Hidraw uses a dynamic major number, meaning that udev should be relied on to
create hidraw device nodes.  Udev will typically create the device nodes
directly under /dev (eg: /dev/hidraw0).  As this location is distribution-
and udev rule-dependent, applications should use libudev to locate hidraw
devices attached to the system.  There is a tutorial on libudev with a
working example at::

        http://www.signal11.us/oss/udev/
        https://web.archive.org/web/2019*/www.signal11.us

read·write report buffer 규칙

39-65

`read()`는 HID device에서 받은 queued report를 읽습니다. USB에서는 device의 INTERRUPT IN endpoint가 보낸 report입니다.

기본적으로 읽을 report가 생길 때까지 block합니다. `open()`에 `O_NONBLOCK`을 주거나 `fcntl()`로 flag를 설정하면 non-blocking으로 만들 수 있습니다.

Numbered report를 사용하는 device에서는 반환 data의 첫 byte가 report number이고 둘째 byte부터 report data가 이어집니다. Numbered report를 사용하지 않으면 첫 byte부터 report data입니다.

`write()`는 report를 device에 씁니다. USB device에 INTERRUPT OUT endpoint가 있으면 그 endpoint로 보내고, 없으면 control endpoint의 SET_REPORT transfer로 보냅니다.

`write()` buffer의 첫 byte는 report number여야 합니다. Numbered report를 사용하지 않으면 첫 byte를 `0`으로 두며 실제 report data는 둘째 byte부터 시작합니다.

read·write buffer
OperationNumbered reportUnnumbered report
readbyte 0 = report number, data = byte 1..data = byte 0..
writebyte 0 = report number, data = byte 1..byte 0 = 0, data = byte 1..

Report ID 사용 여부에 따른 첫 byte 규칙입니다.

USB write endpoint 선택
Application이 report number와 data 구성write() 호출INTERRUPT OUT endpoint 존재 확인있으면 interrupt endpoint로 전송없으면 control endpoint SET_REPORT 사용

Outgoing report가 가능한 endpoint로 전달됩니다.

The HIDRAW API
---------------

read()
-------
read() will read a queued report received from the HID device. On USB
devices, the reports read using read() are the reports sent from the device
on the INTERRUPT IN endpoint.  By default, read() will block until there is
a report available to be read.  read() can be made non-blocking, by passing
the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
fcntl().

On a device which uses numbered reports, the first byte of the returned data
will be the report number; the report data follows, beginning in the second
byte.  For devices which do not use numbered reports, the report data
will begin at the first byte.

write()
-------
The write() function will write a report to the device. For USB devices, if
the device has an INTERRUPT OUT endpoint, the report will be sent on that
endpoint. If it does not, the report will be sent over the control endpoint,
using a SET_REPORT transfer.

The first byte of the buffer passed to write() should be set to the report
number.  If the device does not use numbered reports, the first byte should
be set to 0. The report data itself should begin at the second byte.

Descriptor·device identity ioctl

66-110

Hidraw는 descriptor와 device identity를 위한 여러 ioctl을 지원합니다.

`HIDIOCGRDESCSIZE`는 device report descriptor의 크기를 가져옵니다.

`HIDIOCGRDESC`는 `hidraw_report_descriptor` 구조체로 descriptor를 반환합니다. 구조체의 `size` field를 먼저 `HIDIOCGRDESCSIZE`가 반환한 값으로 설정해야 합니다.

`HIDIOCGRAWINFO`는 bus type, vendor ID(VID), product ID(PID)를 담은 `hidraw_devinfo`를 반환합니다.

Bus type은 `uapi/linux/input.h`에 정의된 `BUS_USB`, `BUS_HIL`, `BUS_BLUETOOTH`, `BUS_VIRTUAL` 중 하나입니다.

`HIDIOCGRAWNAME(len)`은 device의 vendor·product string을 반환합니다. 반환 string은 UTF-8로 encode된 Unicode입니다.

`HIDIOCGRAWPHYS(len)`은 device physical address를 나타내는 string을 반환합니다. USB에서는 controller·hub·port를 포함한 physical path이고 Bluetooth에서는 hardware MAC address입니다.

Hidraw metadata ioctl
Ioctl결과
HIDIOCGRDESCSIZEReport descriptor size
HIDIOCGRDESChidraw_report_descriptor
HIDIOCGRAWINFOBus · VID · PID
HIDIOCGRAWNAME(len)UTF-8 vendor/product name
HIDIOCGRAWPHYS(len)USB physical path 또는 Bluetooth MAC

Descriptor와 identity 조회 API입니다.

Descriptor 읽기
HIDIOCGRDESCSIZE 호출hidraw_report_descriptor.size 설정HIDIOCGRDESC 호출Descriptor byte 수신HID parser·debug tool로 분석

크기를 먼저 얻어 구조체 buffer를 올바르게 준비합니다.


ioctl()
-------
Hidraw supports the following ioctls:

HIDIOCGRDESCSIZE:
        Get Report Descriptor Size

This ioctl will get the size of the device's report descriptor.

HIDIOCGRDESC:
        Get Report Descriptor

This ioctl returns the device's report descriptor using a
hidraw_report_descriptor struct.  Make sure to set the size field of the
hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE.

HIDIOCGRAWINFO:
        Get Raw Info

This ioctl will return a hidraw_devinfo struct containing the bus type, the
vendor ID (VID), and product ID (PID) of the device. The bus type can be one
of::

        - BUS_USB
        - BUS_HIL
        - BUS_BLUETOOTH
        - BUS_VIRTUAL

which are defined in uapi/linux/input.h.

HIDIOCGRAWNAME(len):
        Get Raw Name

This ioctl returns a string containing the vendor and product strings of
the device.  The returned string is Unicode, UTF-8 encoded.

HIDIOCGRAWPHYS(len):
        Get Physical Address

This ioctl returns a string representing the physical address of the device.
For USB devices, the string contains the physical path to the device (the
USB controller, hubs, ports, etc).  For Bluetooth devices, the string
contains the hardware (MAC) address of the device.

Feature Report 송수신

111-130

`HIDIOCSFEATURE(len)`은 feature report를 device로 보냅니다. HID 명세에 따라 feature report는 항상 control endpoint를 사용합니다.

제공 buffer의 첫 byte를 report number로 설정합니다. Numbered report를 사용하지 않으면 첫 byte를 `0`으로 둡니다. Report data는 둘째 byte부터 시작하며 `len`은 report number를 포함하도록 report 길이보다 1 크게 설정해야 합니다.

`HIDIOCGFEATURE(len)`은 control endpoint로 feature report를 요청합니다. 제공 buffer의 첫 byte에 요청할 report number를 넣고, unnumbered device에는 `0`을 넣습니다.

반환 buffer는 첫 byte에 report number, 그 뒤에 device에서 읽은 report data를 담습니다. Unnumbered report device에서는 반환 buffer의 첫 byte부터 report data가 시작합니다.

Feature ioctl buffer
Ioctl입력반환
HIDIOCSFEATUREbyte 0 ID 또는 0 · data byte 1.. · len=data+1Control SET_REPORT 결과
HIDIOCGFEATUREbyte 0에 요청 ID 또는 0ID + data, unnumbered는 data from byte 0

Send와 get의 report-number 처리입니다.

Feature query
요청할 feature Report ID 선택Buffer byte 0에 ID 설정HIDIOCGFEATURE 호출Control endpoint GET_REPORT 수행반환 ID와 payload 해석

Control endpoint에서 특정 feature state를 읽습니다.

HIDIOCSFEATURE(len):
        Send a Feature Report

This ioctl will send a feature report to the device.  Per the HID
specification, feature reports are always sent using the control endpoint.
Set the first byte of the supplied buffer to the report number.  For devices
which do not use numbered reports, set the first byte to 0. The report data
begins in the second byte. Make sure to set len accordingly, to one more
than the length of the report (to account for the report number).

HIDIOCGFEATURE(len):
        Get a Feature Report

This ioctl will request a feature report from the device using the control
endpoint.  The first byte of the supplied buffer should be set to the report
number of the requested report.  For devices which do not use numbered
reports, set the first byte to 0.  The returned report buffer will contain the
report number in the first byte, followed by the report data read from the
device.  For devices which do not use numbered reports, the report data will
begin at the first byte of the returned buffer.

Input Report control request

131-150

`HIDIOCSINPUT(len)`은 control endpoint를 사용해 input report를 device로 보냅니다. 대부분의 device에서 input report를 설정하는 것은 의미가 없고 효과도 없지만, 일부 device는 report의 initial state를 설정하거나 reset하는 데 사용할 수 있습니다.

`HIDIOCSINPUT` buffer 형식은 `HIDIOCSFEATURE`와 같습니다.

`HIDIOCGINPUT(len)`은 control endpoint로 input report를 요청합니다. Regular input report용 전용 IN endpoint가 있는 대부분의 device에서는 더 느리지만 host가 특정 report number의 값을 요청할 수 있습니다.

Application이 일반 `read()` interface로 report를 듣기 전에 device input report의 initial state를 요청하는 데 주로 사용합니다. Buffer 형식은 `HIDIOCGFEATURE`와 같습니다.

Input ioctl
Ioctl용도Buffer
HIDIOCSINPUT특수 device의 initial state set/resetHIDIOCSFEATURE와 동일
HIDIOCGINPUT특정 input report 초기값 queryHIDIOCGFEATURE와 동일
read()정상 input report streamInterrupt IN queued report

일반 interrupt input path와 control query의 차이입니다.

Input 초기 상태
대상 Input Report ID 선택HIDIOCGINPUT control request초기 report state 수신Application state 초기화이후 read()로 regular report stream 처리

Streaming 전에 특정 report의 현재 값을 읽습니다.


HIDIOCSINPUT(len):
        Send an Input Report

This ioctl will send an input report to the device, using the control endpoint.
In most cases, setting an input HID report on a device is meaningless and has
no effect, but some devices may choose to use this to set or reset an initial
state of a report.  The format of the buffer issued with this report is identical
to that of HIDIOCSFEATURE.

HIDIOCGINPUT(len):
        Get an Input Report

This ioctl will request an input report from the device using the control
endpoint.  This is slower on most devices where a dedicated In endpoint exists
for regular input reports, but allows the host to request the value of a
specific report number.  Typically, this is used to request the initial states of
an input report of a device, before an application listens for normal reports via
the regular device read() interface.  The format of the buffer issued with this report
is identical to that of HIDIOCGFEATURE.

Output Report control request

151-169

`HIDIOCSOUTPUT(len)`은 control endpoint로 output report를 device에 보냅니다. Regular output용 전용 OUT endpoint가 있는 대부분의 device에서는 느리지만 API 완전성을 위해 제공됩니다.

Application이 일반 `write()`로 update를 보내기 전에 output report의 initial state를 설정하는 데 주로 사용합니다. Buffer 형식은 `HIDIOCSFEATURE`와 같습니다.

`HIDIOCGOUTPUT(len)`은 control endpoint로 output report를 요청합니다. Application이 `HIDIOCSOUTPUT` 또는 일반 `write()`로 update하기 전에 현재 initial state를 가져오는 데 주로 사용합니다.

`HIDIOCGOUTPUT` buffer 형식은 `HIDIOCGFEATURE`와 같습니다.

Output ioctl
Ioctl동작
HIDIOCSOUTPUTControl endpoint로 output state 설정
HIDIOCGOUTPUTControl endpoint로 output state 조회
write()Regular output update, interrupt OUT 또는 SET_REPORT

초기 state와 regular update 경로를 구분합니다.

Output state 관리
HIDIOCGOUTPUT으로 current state 요청Application이 새 output payload 구성초기 설정은 HIDIOCSOUTPUT 가능Regular update는 write() 사용Transport가 interrupt OUT 또는 control 선택

초기값 조회 후 필요한 방식으로 update합니다.


HIDIOCSOUTPUT(len):
        Send an Output Report

This ioctl will send an output report to the device, using the control endpoint.
This is slower on most devices where a dedicated Out endpoint exists for regular
output reports, but is added for completeness.  Typically, this is used to set
the initial states of an output report of a device, before an application sends
updates via the regular device write() interface. The format of the buffer issued
with this report is identical to that of HIDIOCSFEATURE.

HIDIOCGOUTPUT(len):
        Get an Output Report

This ioctl will request an output report from the device using the control
endpoint.  Typically, this is used to retrieve the initial state of
an output report of a device, before an application updates it as necessary either
via a HIDIOCSOUTPUT request, or the regular device write() interface.  The format
of the buffer issued with this report is identical to that of HIDIOCGFEATURE.

hid-example.c와 문서 저자

170-180

`samples/`의 `hid-example.c`는 hidraw의 `read()`, `write()`와 모든 ioctl 사용 예를 보여 줍니다.

이 code는 누구든 어떤 목적으로든 사용할 수 있으며 hidraw application 개발의 시작점으로 쓸 수 있습니다.

문서는 Signal 11 Software의 Alan Ott가 작성했습니다.

Hidraw example 범위
예제내용
read()Queued raw report 수신
write()Raw output report 전송
ioctl()Descriptor·identity·feature/input/output 제어

Sample에서 확인할 수 있는 API입니다.

Sample 활용
samples/hidraw/hid-example.c 확인대상 device VID·PID 탐색Descriptor와 report size 읽기Raw read/write 검증필요한 ioctl만 application에 통합

기본 example을 device-specific application으로 확장합니다.


Example
-------
In samples/, find hid-example.c, which shows examples of read(), write(),
and all the ioctls for hidraw.  The code may be used by anyone for any
purpose, and can serve as a starting point for developing applications using
hidraw.

Document by:

        Alan Ott <[email protected]>, Signal 11 Software