Documentation/media/uapi/rc/rc-protos.rst

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