summaryrefslogtreecommitdiff
path: root/Documentation/media/uapi/rc/rc-protos.rst
blob: b250ebe301d555b208b806b2a5c2a8c541e08bc9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
.. SPDX-License-Identifier: GPL-2.0
..
.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections

.. _Remote_controllers_Protocols:

*****************************************
Remote Controller Protocols and Scancodes
*****************************************

IR is encoded as a series of pulses and spaces, using a protocol. These
protocols can encode e.g. an address (which device should respond) and a
command: what it should do. The values for these are not always consistent
across different devices for a given protocol.

Therefore out the output of the IR decoder is a scancode; a single u32
value. Using keymap tables this can be mapped to linux key codes.

Other things can be encoded too. Some IR protocols encode a toggle bit; this
is to distinguish whether the same button is being held down, or has been
released and pressed again. If has been released and pressed again, the
toggle bit will invert from one IR message to the next.

Some remotes have a pointer-type device which can used to control the
mouse; some air conditioning systems can have their target temperature
target set in IR.

The following are the protocols the kernel knows about and also lists
how scancodes are encoded for each protocol.

rc-5 (RC_PROTO_RC5)
-------------------

This IR protocol uses manchester encoding to encode 14 bits. There is a
detailed description here https://www.sbprojects.net/knowledge/ir/rc5.php.

The scancode encoding is *not* consistent with the lirc daemon (lircd) rc5
protocol, or the manchester BPF decoder.

.. flat-table:: rc5 bits scancode mapping
   :widths:       1 1 2

   * - rc-5 bit

     - scancode bit

     - description

   * - 1

     - none

     - Start bit, always set

   * - 1

     - 6 (inverted)

     - 2nd start bit in rc5,  re-used as 6th command bit

   * - 1

     - none

     - Toggle bit

   * - 5

     - 8 to 13

     - Address

   * - 6

     - 0 to 5

     - Command

There is a variant of rc5 called either rc5x or extended rc5
where there the second stop bit is the 6th commmand bit, but inverted.
This is done so it the scancodes and encoding is compatible with existing
schemes. This bit is stored in bit 6 of the scancode, inverted. This is
done to keep it compatible with plain rc-5 where there are two start bits.

rc-5-sz (RC_PROTO_RC5_SZ)
-------------------------
This is much like rc-5 but one bit longer. The scancode is encoded
differently.

.. flat-table:: rc-5-sz bits scancode mapping
   :widths:       1 1 2

   * - rc-5-sz bits

     - scancode bit

     - description

   * - 1

     - none

     - Start bit, always set

   * - 1

     - 13

     - Address bit

   * - 1

     - none

     - Toggle bit

   * - 6

     - 6 to 11

     - Address

   * - 6

     - 0 to 5

     - Command

rc-5x-20 (RC_PROTO_RC5X_20)
---------------------------

This rc-5 extended to encoded 20 bits. The is a 3555 microseconds space
after the 8th bit.

.. flat-table:: rc-5x-20 bits scancode mapping
   :widths:       1 1 2

   * - rc-5-sz bits

     - scancode bit

     - description

   * - 1

     - none

     - Start bit, always set

   * - 1

     - 14

     - Address bit

   * - 1

     - none

     - Toggle bit

   * - 5

     - 16 to 20

     - Address

   * - 6

     - 8 to 13

     - Address

   * - 6

     - 0 to 5

     - Command


jvc (RC_PROTO_JVC)
------------------

The jvc protocol is much like nec, without the inverted values. It is
described here https://www.sbprojects.net/knowledge/ir/jvc.php.

The scancode is a 16 bits value, where the address is the lower 8 bits
and the command the higher 8 bits; this is reversed from IR order.

sony-12 (RC_PROTO_SONY12)
-------------------------

The sony protocol is a pulse-width encoding. There are three variants,
which just differ in number of bits and scancode encoding.

.. flat-table:: sony-12 bits scancode mapping
   :widths:       1 1 2

   * - sony-12 bits

     - scancode bit

     - description

   * - 5

     - 16 to 20

     - device

   * - 7

     - 0 to 6

     - function

sony-15 (RC_PROTO_SONY15)
-------------------------

The sony protocol is a pulse-width encoding. There are three variants,
which just differ in number of bits and scancode encoding.

.. flat-table:: sony-12 bits scancode mapping
   :widths:       1 1 2

   * - sony-12 bits

     - scancode bit

     - description

   * - 8

     - 16 to 23

     - device

   * - 7

     - 0 to 6

     - function

sony-20 (RC_PROTO_SONY20)
-------------------------

The sony protocol is a pulse-width encoding. There are three variants,
which just differ in number of bits and scancode encoding.

.. flat-table:: sony-20 bits scancode mapping
   :widths:       1 1 2

   * - sony-20 bits

     - scancode bit

     - description

   * - 5

     - 16 to 20

     - device

   * - 7

     - 0 to 7

     - device

   * - 8

     - 8 to 15

     - extended bits

nec (RC_PROTO_NEC)
------------------

The nec protocol encodes an 8 bit address and an 8 bit command. It is
described here https://www.sbprojects.net/knowledge/ir/nec.php. Note
that the protocol sends least significant bit first.

As a check, the nec protocol sends the address and command twice; the
second time it is inverted. This is done for verification.

A plain nec IR message has 16 bits; the high 8 bits are the address
and the low 8 bits are the command.

nec-x (RC_PROTO_NECX)
---------------------

Extended nec has a 16 bit address and a 8 bit command. This is encoded
as a 24 bit value as you would expect, with the lower 8 bits the command
and the upper 16 bits the address.

nec-32 (RC_PROTO_NEC32)
-----------------------

nec-32 does not send an inverted address or an inverted command; the
entire message, all 32 bits, are used.

For this to be decoded correctly, the second 8 bits must not be the
inverted value of the first, and also the last 8 bits must not be the
inverted value of the third 8 bit value.

The scancode has a somewhat unusual encoding.

.. flat-table:: nec-32 bits scancode mapping

   * - nec-32 bits

     - scancode bit

   * - First 8 bits

     - 16 to 23

   * - Second 8 bits

     - 24 to 31

   * - Third 8 bits

     - 0 to 7

   * - Fourth 8 bits

     - 8 to 15

sanyo (RC_PROTO_SANYO)
----------------------

The sanyo protocol is like the nec protocol, but with 13 bits address
rather than 8 bits. Both the address and the command are followed by
their inverted versions, but these are not present in the scancodes.

Bis 8 to 20 of the scancode is the 13 bits address, and the lower 8
bits are the command.

mcir2-kbd (RC_PROTO_MCIR2_KBD)
------------------------------

This protocol is generated by the Microsoft MCE keyboard for keyboard
events. Refer to the ir-mce_kbd-decoder.c to see how it is encoded.

mcir2-mse (RC_PROTO_MCIR2_MSE)
------------------------------

This protocol is generated by the Microsoft MCE keyboard for pointer
events. Refer to the ir-mce_kbd-decoder.c to see how it is encoded.

rc-6-0 (RC_PROTO_RC6_0)
-----------------------

This is the rc-6 in mode 0. rc-6 is described here
https://www.sbprojects.net/knowledge/ir/rc6.php.
The scancode is the exact 16 bits as in the protocol. There is also a
toggle bit.

rc-6-6a-20 (RC_PROTO_RC6_6A_20)
-------------------------------

This is the rc-6 in mode 6a, 20 bits. rc-6 is described here
https://www.sbprojects.net/knowledge/ir/rc6.php.
The scancode is the exact 20 bits
as in the protocol. There is also a toggle bit.

rc-6-6a-24 (RC_PROTO_RC6_6A_24)
-------------------------------

This is the rc-6 in mode 6a, 24 bits. rc-6 is described here
https://www.sbprojects.net/knowledge/ir/rc6.php.
The scancode is the exact 24 bits
as in the protocol. There is also a toggle bit.

rc-6-6a-32 (RC_PROTO_RC6_6A_32)
-------------------------------

This is the rc-6 in mode 6a, 32 bits. rc-6 is described here
https://www.sbprojects.net/knowledge/ir/rc6.php.
The upper 16 bits are the vendor,
and the lower 16 bits are the vendor-specific bits. This protocol is
for the non-Microsoft MCE variant (vendor != 0x800f).


rc-6-mce (RC_PROTO_RC6_MCE)
---------------------------

This is the rc-6 in mode 6a, 32 bits. The upper 16 bits are the vendor,
and the lower 16 bits are the vendor-specific bits. This protocol is
for the Microsoft MCE variant (vendor = 0x800f). The toggle bit in the
protocol itself is ignored, and the 16th bit should be takes as the toggle
bit.

sharp (RC_PROTO_SHARP)
----------------------

This is a protocol used by Sharp VCRs, is described here
https://www.sbprojects.net/knowledge/ir/sharp.php. There is a very long
(40ms) space between the normal and inverted values, and some IR receivers
cannot decode this.

There is a 5 bit address and a 8 bit command. In the scancode the address is
in bits 8 to 12, and the command in bits 0 to 7.

xmp (RC_PROTO_XMP)
------------------

This protocol has several versions and only version 1 is supported. Refer
to the decoder (ir-xmp-decoder.c) to see how it is encoded.


cec (RC_PROTO_CEC)
------------------

This is not an IR protocol, this is a protocol over CEC. The CEC
infrastructure uses rc-core for handling CEC commands, so that they
can easily be remapped.

imon (RC_PROTO_IMON)
--------------------

This protocol is used by Antec Veris/SoundGraph iMON remotes.

The protocol
describes both button presses and pointer movements. The protocol encodes
31 bits, and the scancode is simply the 31 bits with the top bit always 0.

rc-mm-12 (RC_PROTO_RCMM12)
--------------------------

The rc-mm protocol is described here
https://www.sbprojects.net/knowledge/ir/rcmm.php. The scancode is simply
the 12 bits.

rc-mm-24 (RC_PROTO_RCMM24)
--------------------------

The rc-mm protocol is described here
https://www.sbprojects.net/knowledge/ir/rcmm.php. The scancode is simply
the 24 bits.

rc-mm-32 (RC_PROTO_RCMM32)
--------------------------

The rc-mm protocol is described here
https://www.sbprojects.net/knowledge/ir/rcmm.php. The scancode is simply
the 32 bits.

xbox-dvd (RC_PROTO_XBOX_DVD)
----------------------------

This protocol is used by XBox DVD Remote, which was made for the original
XBox. There is no in-kernel decoder or encoder for this protocol. The usb
device decodes the protocol. There is a BPF decoder available in v4l-utils.