Commit | Line | Data |
---|---|---|
ac7f9d02 | 1 | .. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later |
7328d682 SY |
2 | |
3 | .. _Remote_controllers_Protocols: | |
4 | ||
5 | ***************************************** | |
6 | Remote Controller Protocols and Scancodes | |
7 | ***************************************** | |
8 | ||
9 | IR is encoded as a series of pulses and spaces, using a protocol. These | |
10 | protocols can encode e.g. an address (which device should respond) and a | |
11 | command: what it should do. The values for these are not always consistent | |
12 | across different devices for a given protocol. | |
13 | ||
14 | Therefore out the output of the IR decoder is a scancode; a single u32 | |
15 | value. Using keymap tables this can be mapped to linux key codes. | |
16 | ||
17 | Other things can be encoded too. Some IR protocols encode a toggle bit; this | |
18 | is to distinguish whether the same button is being held down, or has been | |
19 | released and pressed again. If has been released and pressed again, the | |
20 | toggle bit will invert from one IR message to the next. | |
21 | ||
22 | Some remotes have a pointer-type device which can used to control the | |
23 | mouse; some air conditioning systems can have their target temperature | |
24 | target set in IR. | |
25 | ||
26 | The following are the protocols the kernel knows about and also lists | |
27 | how scancodes are encoded for each protocol. | |
28 | ||
29 | rc-5 (RC_PROTO_RC5) | |
30 | ------------------- | |
31 | ||
32 | This IR protocol uses manchester encoding to encode 14 bits. There is a | |
33 | detailed description here https://www.sbprojects.net/knowledge/ir/rc5.php. | |
34 | ||
35 | The scancode encoding is *not* consistent with the lirc daemon (lircd) rc5 | |
36 | protocol, or the manchester BPF decoder. | |
37 | ||
38 | .. flat-table:: rc5 bits scancode mapping | |
39 | :widths: 1 1 2 | |
40 | ||
41 | * - rc-5 bit | |
42 | ||
43 | - scancode bit | |
44 | ||
45 | - description | |
46 | ||
47 | * - 1 | |
48 | ||
49 | - none | |
50 | ||
51 | - Start bit, always set | |
52 | ||
53 | * - 1 | |
54 | ||
55 | - 6 (inverted) | |
56 | ||
57 | - 2nd start bit in rc5, re-used as 6th command bit | |
58 | ||
59 | * - 1 | |
60 | ||
61 | - none | |
62 | ||
63 | - Toggle bit | |
64 | ||
65 | * - 5 | |
66 | ||
67 | - 8 to 13 | |
68 | ||
69 | - Address | |
70 | ||
71 | * - 6 | |
72 | ||
73 | - 0 to 5 | |
74 | ||
75 | - Command | |
76 | ||
77 | There is a variant of rc5 called either rc5x or extended rc5 | |
c1966bd1 | 78 | where there the second stop bit is the 6th command bit, but inverted. |
7328d682 SY |
79 | This is done so it the scancodes and encoding is compatible with existing |
80 | schemes. This bit is stored in bit 6 of the scancode, inverted. This is | |
81 | done to keep it compatible with plain rc-5 where there are two start bits. | |
82 | ||
83 | rc-5-sz (RC_PROTO_RC5_SZ) | |
84 | ------------------------- | |
85 | This is much like rc-5 but one bit longer. The scancode is encoded | |
86 | differently. | |
87 | ||
88 | .. flat-table:: rc-5-sz bits scancode mapping | |
89 | :widths: 1 1 2 | |
90 | ||
91 | * - rc-5-sz bits | |
92 | ||
93 | - scancode bit | |
94 | ||
95 | - description | |
96 | ||
97 | * - 1 | |
98 | ||
99 | - none | |
100 | ||
101 | - Start bit, always set | |
102 | ||
103 | * - 1 | |
104 | ||
105 | - 13 | |
106 | ||
107 | - Address bit | |
108 | ||
109 | * - 1 | |
110 | ||
111 | - none | |
112 | ||
113 | - Toggle bit | |
114 | ||
115 | * - 6 | |
116 | ||
117 | - 6 to 11 | |
118 | ||
119 | - Address | |
120 | ||
121 | * - 6 | |
122 | ||
123 | - 0 to 5 | |
124 | ||
125 | - Command | |
126 | ||
127 | rc-5x-20 (RC_PROTO_RC5X_20) | |
128 | --------------------------- | |
129 | ||
130 | This rc-5 extended to encoded 20 bits. The is a 3555 microseconds space | |
131 | after the 8th bit. | |
132 | ||
133 | .. flat-table:: rc-5x-20 bits scancode mapping | |
134 | :widths: 1 1 2 | |
135 | ||
136 | * - rc-5-sz bits | |
137 | ||
138 | - scancode bit | |
139 | ||
140 | - description | |
141 | ||
142 | * - 1 | |
143 | ||
144 | - none | |
145 | ||
146 | - Start bit, always set | |
147 | ||
148 | * - 1 | |
149 | ||
150 | - 14 | |
151 | ||
152 | - Address bit | |
153 | ||
154 | * - 1 | |
155 | ||
156 | - none | |
157 | ||
158 | - Toggle bit | |
159 | ||
160 | * - 5 | |
161 | ||
162 | - 16 to 20 | |
163 | ||
164 | - Address | |
165 | ||
166 | * - 6 | |
167 | ||
168 | - 8 to 13 | |
169 | ||
170 | - Address | |
171 | ||
172 | * - 6 | |
173 | ||
174 | - 0 to 5 | |
175 | ||
176 | - Command | |
177 | ||
178 | ||
179 | jvc (RC_PROTO_JVC) | |
180 | ------------------ | |
181 | ||
182 | The jvc protocol is much like nec, without the inverted values. It is | |
183 | described here https://www.sbprojects.net/knowledge/ir/jvc.php. | |
184 | ||
185 | The scancode is a 16 bits value, where the address is the lower 8 bits | |
186 | and the command the higher 8 bits; this is reversed from IR order. | |
187 | ||
188 | sony-12 (RC_PROTO_SONY12) | |
189 | ------------------------- | |
190 | ||
191 | The sony protocol is a pulse-width encoding. There are three variants, | |
192 | which just differ in number of bits and scancode encoding. | |
193 | ||
194 | .. flat-table:: sony-12 bits scancode mapping | |
195 | :widths: 1 1 2 | |
196 | ||
197 | * - sony-12 bits | |
198 | ||
199 | - scancode bit | |
200 | ||
201 | - description | |
202 | ||
203 | * - 5 | |
204 | ||
205 | - 16 to 20 | |
206 | ||
207 | - device | |
208 | ||
209 | * - 7 | |
210 | ||
211 | - 0 to 6 | |
212 | ||
213 | - function | |
214 | ||
215 | sony-15 (RC_PROTO_SONY15) | |
216 | ------------------------- | |
217 | ||
218 | The sony protocol is a pulse-width encoding. There are three variants, | |
219 | which just differ in number of bits and scancode encoding. | |
220 | ||
221 | .. flat-table:: sony-12 bits scancode mapping | |
222 | :widths: 1 1 2 | |
223 | ||
224 | * - sony-12 bits | |
225 | ||
226 | - scancode bit | |
227 | ||
228 | - description | |
229 | ||
230 | * - 8 | |
231 | ||
232 | - 16 to 23 | |
233 | ||
234 | - device | |
235 | ||
236 | * - 7 | |
237 | ||
238 | - 0 to 6 | |
239 | ||
240 | - function | |
241 | ||
242 | sony-20 (RC_PROTO_SONY20) | |
243 | ------------------------- | |
244 | ||
245 | The sony protocol is a pulse-width encoding. There are three variants, | |
246 | which just differ in number of bits and scancode encoding. | |
247 | ||
248 | .. flat-table:: sony-20 bits scancode mapping | |
249 | :widths: 1 1 2 | |
250 | ||
251 | * - sony-20 bits | |
252 | ||
253 | - scancode bit | |
254 | ||
255 | - description | |
256 | ||
257 | * - 5 | |
258 | ||
259 | - 16 to 20 | |
260 | ||
261 | - device | |
262 | ||
263 | * - 7 | |
264 | ||
265 | - 0 to 7 | |
266 | ||
267 | - device | |
268 | ||
269 | * - 8 | |
270 | ||
271 | - 8 to 15 | |
272 | ||
273 | - extended bits | |
274 | ||
275 | nec (RC_PROTO_NEC) | |
276 | ------------------ | |
277 | ||
278 | The nec protocol encodes an 8 bit address and an 8 bit command. It is | |
279 | described here https://www.sbprojects.net/knowledge/ir/nec.php. Note | |
280 | that the protocol sends least significant bit first. | |
281 | ||
282 | As a check, the nec protocol sends the address and command twice; the | |
283 | second time it is inverted. This is done for verification. | |
284 | ||
285 | A plain nec IR message has 16 bits; the high 8 bits are the address | |
286 | and the low 8 bits are the command. | |
287 | ||
288 | nec-x (RC_PROTO_NECX) | |
289 | --------------------- | |
290 | ||
291 | Extended nec has a 16 bit address and a 8 bit command. This is encoded | |
292 | as a 24 bit value as you would expect, with the lower 8 bits the command | |
293 | and the upper 16 bits the address. | |
294 | ||
295 | nec-32 (RC_PROTO_NEC32) | |
296 | ----------------------- | |
297 | ||
298 | nec-32 does not send an inverted address or an inverted command; the | |
299 | entire message, all 32 bits, are used. | |
300 | ||
301 | For this to be decoded correctly, the second 8 bits must not be the | |
302 | inverted value of the first, and also the last 8 bits must not be the | |
303 | inverted value of the third 8 bit value. | |
304 | ||
305 | The scancode has a somewhat unusual encoding. | |
306 | ||
307 | .. flat-table:: nec-32 bits scancode mapping | |
308 | ||
309 | * - nec-32 bits | |
310 | ||
311 | - scancode bit | |
312 | ||
313 | * - First 8 bits | |
314 | ||
315 | - 16 to 23 | |
316 | ||
317 | * - Second 8 bits | |
318 | ||
319 | - 24 to 31 | |
320 | ||
321 | * - Third 8 bits | |
322 | ||
323 | - 0 to 7 | |
324 | ||
325 | * - Fourth 8 bits | |
326 | ||
327 | - 8 to 15 | |
328 | ||
329 | sanyo (RC_PROTO_SANYO) | |
330 | ---------------------- | |
331 | ||
332 | The sanyo protocol is like the nec protocol, but with 13 bits address | |
333 | rather than 8 bits. Both the address and the command are followed by | |
334 | their inverted versions, but these are not present in the scancodes. | |
335 | ||
336 | Bis 8 to 20 of the scancode is the 13 bits address, and the lower 8 | |
337 | bits are the command. | |
338 | ||
339 | mcir2-kbd (RC_PROTO_MCIR2_KBD) | |
340 | ------------------------------ | |
341 | ||
342 | This protocol is generated by the Microsoft MCE keyboard for keyboard | |
343 | events. Refer to the ir-mce_kbd-decoder.c to see how it is encoded. | |
344 | ||
345 | mcir2-mse (RC_PROTO_MCIR2_MSE) | |
346 | ------------------------------ | |
347 | ||
348 | This protocol is generated by the Microsoft MCE keyboard for pointer | |
349 | events. Refer to the ir-mce_kbd-decoder.c to see how it is encoded. | |
350 | ||
351 | rc-6-0 (RC_PROTO_RC6_0) | |
352 | ----------------------- | |
353 | ||
354 | This is the rc-6 in mode 0. rc-6 is described here | |
355 | https://www.sbprojects.net/knowledge/ir/rc6.php. | |
356 | The scancode is the exact 16 bits as in the protocol. There is also a | |
357 | toggle bit. | |
358 | ||
359 | rc-6-6a-20 (RC_PROTO_RC6_6A_20) | |
360 | ------------------------------- | |
361 | ||
362 | This is the rc-6 in mode 6a, 20 bits. rc-6 is described here | |
363 | https://www.sbprojects.net/knowledge/ir/rc6.php. | |
364 | The scancode is the exact 20 bits | |
365 | as in the protocol. There is also a toggle bit. | |
366 | ||
367 | rc-6-6a-24 (RC_PROTO_RC6_6A_24) | |
368 | ------------------------------- | |
369 | ||
370 | This is the rc-6 in mode 6a, 24 bits. rc-6 is described here | |
371 | https://www.sbprojects.net/knowledge/ir/rc6.php. | |
372 | The scancode is the exact 24 bits | |
373 | as in the protocol. There is also a toggle bit. | |
374 | ||
375 | rc-6-6a-32 (RC_PROTO_RC6_6A_32) | |
376 | ------------------------------- | |
377 | ||
378 | This is the rc-6 in mode 6a, 32 bits. rc-6 is described here | |
379 | https://www.sbprojects.net/knowledge/ir/rc6.php. | |
380 | The upper 16 bits are the vendor, | |
381 | and the lower 16 bits are the vendor-specific bits. This protocol is | |
382 | for the non-Microsoft MCE variant (vendor != 0x800f). | |
383 | ||
384 | ||
385 | rc-6-mce (RC_PROTO_RC6_MCE) | |
386 | --------------------------- | |
387 | ||
388 | This is the rc-6 in mode 6a, 32 bits. The upper 16 bits are the vendor, | |
389 | and the lower 16 bits are the vendor-specific bits. This protocol is | |
390 | for the Microsoft MCE variant (vendor = 0x800f). The toggle bit in the | |
391 | protocol itself is ignored, and the 16th bit should be takes as the toggle | |
392 | bit. | |
393 | ||
394 | sharp (RC_PROTO_SHARP) | |
395 | ---------------------- | |
396 | ||
397 | This is a protocol used by Sharp VCRs, is described here | |
398 | https://www.sbprojects.net/knowledge/ir/sharp.php. There is a very long | |
399 | (40ms) space between the normal and inverted values, and some IR receivers | |
400 | cannot decode this. | |
401 | ||
402 | There is a 5 bit address and a 8 bit command. In the scancode the address is | |
403 | in bits 8 to 12, and the command in bits 0 to 7. | |
404 | ||
405 | xmp (RC_PROTO_XMP) | |
406 | ------------------ | |
407 | ||
408 | This protocol has several versions and only version 1 is supported. Refer | |
409 | to the decoder (ir-xmp-decoder.c) to see how it is encoded. | |
410 | ||
411 | ||
412 | cec (RC_PROTO_CEC) | |
413 | ------------------ | |
414 | ||
415 | This is not an IR protocol, this is a protocol over CEC. The CEC | |
416 | infrastructure uses rc-core for handling CEC commands, so that they | |
417 | can easily be remapped. | |
418 | ||
419 | imon (RC_PROTO_IMON) | |
420 | -------------------- | |
421 | ||
422 | This protocol is used by Antec Veris/SoundGraph iMON remotes. | |
423 | ||
424 | The protocol | |
425 | describes both button presses and pointer movements. The protocol encodes | |
426 | 31 bits, and the scancode is simply the 31 bits with the top bit always 0. | |
427 | ||
428 | rc-mm-12 (RC_PROTO_RCMM12) | |
429 | -------------------------- | |
430 | ||
431 | The rc-mm protocol is described here | |
432 | https://www.sbprojects.net/knowledge/ir/rcmm.php. The scancode is simply | |
433 | the 12 bits. | |
434 | ||
435 | rc-mm-24 (RC_PROTO_RCMM24) | |
436 | -------------------------- | |
437 | ||
438 | The rc-mm protocol is described here | |
439 | https://www.sbprojects.net/knowledge/ir/rcmm.php. The scancode is simply | |
440 | the 24 bits. | |
441 | ||
442 | rc-mm-32 (RC_PROTO_RCMM32) | |
443 | -------------------------- | |
444 | ||
445 | The rc-mm protocol is described here | |
446 | https://www.sbprojects.net/knowledge/ir/rcmm.php. The scancode is simply | |
447 | the 32 bits. | |
448 | ||
449 | xbox-dvd (RC_PROTO_XBOX_DVD) | |
450 | ---------------------------- | |
451 | ||
452 | This protocol is used by XBox DVD Remote, which was made for the original | |
453 | XBox. There is no in-kernel decoder or encoder for this protocol. The usb | |
454 | device decodes the protocol. There is a BPF decoder available in v4l-utils. |