18c2ecf20Sopenharmony_ci.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later 28c2ecf20Sopenharmony_ci 38c2ecf20Sopenharmony_ci.. _lirc_dev_intro: 48c2ecf20Sopenharmony_ci 58c2ecf20Sopenharmony_ci************ 68c2ecf20Sopenharmony_ciIntroduction 78c2ecf20Sopenharmony_ci************ 88c2ecf20Sopenharmony_ci 98c2ecf20Sopenharmony_ciLIRC stands for Linux Infrared Remote Control. The LIRC device interface is 108c2ecf20Sopenharmony_cia bi-directional interface for transporting raw IR and decoded scancodes 118c2ecf20Sopenharmony_cidata between userspace and kernelspace. Fundamentally, it is just a chardev 128c2ecf20Sopenharmony_ci(/dev/lircX, for X = 0, 1, 2, ...), with a number of standard struct 138c2ecf20Sopenharmony_cifile_operations defined on it. With respect to transporting raw IR and 148c2ecf20Sopenharmony_cidecoded scancodes to and fro, the essential fops are read, write and ioctl. 158c2ecf20Sopenharmony_ci 168c2ecf20Sopenharmony_ciIt is also possible to attach a BPF program to a LIRC device for decoding 178c2ecf20Sopenharmony_ciraw IR into scancodes. 188c2ecf20Sopenharmony_ci 198c2ecf20Sopenharmony_ciExample dmesg output upon a driver registering w/LIRC: 208c2ecf20Sopenharmony_ci 218c2ecf20Sopenharmony_ci.. code-block:: none 228c2ecf20Sopenharmony_ci 238c2ecf20Sopenharmony_ci $ dmesg |grep lirc_dev 248c2ecf20Sopenharmony_ci rc rc0: lirc_dev: driver mceusb registered at minor = 0, raw IR receiver, raw IR transmitter 258c2ecf20Sopenharmony_ci 268c2ecf20Sopenharmony_ciWhat you should see for a chardev: 278c2ecf20Sopenharmony_ci 288c2ecf20Sopenharmony_ci.. code-block:: none 298c2ecf20Sopenharmony_ci 308c2ecf20Sopenharmony_ci $ ls -l /dev/lirc* 318c2ecf20Sopenharmony_ci crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0 328c2ecf20Sopenharmony_ci 338c2ecf20Sopenharmony_ciNote that the package `v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_ 348c2ecf20Sopenharmony_cicontains tools for working with LIRC devices: 358c2ecf20Sopenharmony_ci 368c2ecf20Sopenharmony_ci - ir-ctl: can receive raw IR and transmit IR, as well as query LIRC 378c2ecf20Sopenharmony_ci device features. 388c2ecf20Sopenharmony_ci 398c2ecf20Sopenharmony_ci - ir-keytable: can load keymaps; allows you to set IR kernel protocols; load 408c2ecf20Sopenharmony_ci BPF IR decoders and test IR decoding. Some BPF IR decoders are also 418c2ecf20Sopenharmony_ci provided. 428c2ecf20Sopenharmony_ci 438c2ecf20Sopenharmony_ci.. _lirc_modes: 448c2ecf20Sopenharmony_ci 458c2ecf20Sopenharmony_ci********** 468c2ecf20Sopenharmony_ciLIRC modes 478c2ecf20Sopenharmony_ci********** 488c2ecf20Sopenharmony_ci 498c2ecf20Sopenharmony_ciLIRC supports some modes of receiving and sending IR codes, as shown 508c2ecf20Sopenharmony_cion the following table. 518c2ecf20Sopenharmony_ci 528c2ecf20Sopenharmony_ci.. _lirc-mode-scancode: 538c2ecf20Sopenharmony_ci.. _lirc-scancode-flag-toggle: 548c2ecf20Sopenharmony_ci.. _lirc-scancode-flag-repeat: 558c2ecf20Sopenharmony_ci 568c2ecf20Sopenharmony_ci``LIRC_MODE_SCANCODE`` 578c2ecf20Sopenharmony_ci 588c2ecf20Sopenharmony_ci This mode is for both sending and receiving IR. 598c2ecf20Sopenharmony_ci 608c2ecf20Sopenharmony_ci For transmitting (aka sending), create a ``struct lirc_scancode`` with 618c2ecf20Sopenharmony_ci the desired scancode set in the ``scancode`` member, :c:type:`rc_proto` 628c2ecf20Sopenharmony_ci set to the :ref:`IR protocol <Remote_controllers_Protocols>`, and all other 638c2ecf20Sopenharmony_ci members set to 0. Write this struct to the lirc device. 648c2ecf20Sopenharmony_ci 658c2ecf20Sopenharmony_ci For receiving, you read ``struct lirc_scancode`` from the LIRC device. 668c2ecf20Sopenharmony_ci The ``scancode`` field is set to the received scancode and the 678c2ecf20Sopenharmony_ci :ref:`IR protocol <Remote_controllers_Protocols>` is set in 688c2ecf20Sopenharmony_ci :c:type:`rc_proto`. If the scancode maps to a valid key code, this is set 698c2ecf20Sopenharmony_ci in the ``keycode`` field, else it is set to ``KEY_RESERVED``. 708c2ecf20Sopenharmony_ci 718c2ecf20Sopenharmony_ci The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set if the toggle 728c2ecf20Sopenharmony_ci bit is set in protocols that support it (e.g. rc-5 and rc-6), or 738c2ecf20Sopenharmony_ci ``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for protocols 748c2ecf20Sopenharmony_ci that support it (e.g. nec). 758c2ecf20Sopenharmony_ci 768c2ecf20Sopenharmony_ci In the Sanyo and NEC protocol, if you hold a button on remote, rather than 778c2ecf20Sopenharmony_ci repeating the entire scancode, the remote sends a shorter message with 788c2ecf20Sopenharmony_ci no scancode, which just means button is held, a "repeat". When this is 798c2ecf20Sopenharmony_ci received, the ``LIRC_SCANCODE_FLAG_REPEAT`` is set and the scancode and 808c2ecf20Sopenharmony_ci keycode is repeated. 818c2ecf20Sopenharmony_ci 828c2ecf20Sopenharmony_ci With nec, there is no way to distinguish "button hold" from "repeatedly 838c2ecf20Sopenharmony_ci pressing the same button". The rc-5 and rc-6 protocols have a toggle bit. 848c2ecf20Sopenharmony_ci When a button is released and pressed again, the toggle bit is inverted. 858c2ecf20Sopenharmony_ci If the toggle bit is set, the ``LIRC_SCANCODE_FLAG_TOGGLE`` is set. 868c2ecf20Sopenharmony_ci 878c2ecf20Sopenharmony_ci The ``timestamp`` field is filled with the time nanoseconds 888c2ecf20Sopenharmony_ci (in ``CLOCK_MONOTONIC``) when the scancode was decoded. 898c2ecf20Sopenharmony_ci 908c2ecf20Sopenharmony_ci.. _lirc-mode-mode2: 918c2ecf20Sopenharmony_ci 928c2ecf20Sopenharmony_ci``LIRC_MODE_MODE2`` 938c2ecf20Sopenharmony_ci 948c2ecf20Sopenharmony_ci The driver returns a sequence of pulse and space codes to userspace, 958c2ecf20Sopenharmony_ci as a series of u32 values. 968c2ecf20Sopenharmony_ci 978c2ecf20Sopenharmony_ci This mode is used only for IR receive. 988c2ecf20Sopenharmony_ci 998c2ecf20Sopenharmony_ci The upper 8 bits determine the packet type, and the lower 24 bits 1008c2ecf20Sopenharmony_ci the payload. Use ``LIRC_VALUE()`` macro to get the payload, and 1018c2ecf20Sopenharmony_ci the macro ``LIRC_MODE2()`` will give you the type, which 1028c2ecf20Sopenharmony_ci is one of: 1038c2ecf20Sopenharmony_ci 1048c2ecf20Sopenharmony_ci ``LIRC_MODE2_PULSE`` 1058c2ecf20Sopenharmony_ci 1068c2ecf20Sopenharmony_ci Signifies the presence of IR in microseconds. 1078c2ecf20Sopenharmony_ci 1088c2ecf20Sopenharmony_ci ``LIRC_MODE2_SPACE`` 1098c2ecf20Sopenharmony_ci 1108c2ecf20Sopenharmony_ci Signifies absence of IR in microseconds. 1118c2ecf20Sopenharmony_ci 1128c2ecf20Sopenharmony_ci ``LIRC_MODE2_FREQUENCY`` 1138c2ecf20Sopenharmony_ci 1148c2ecf20Sopenharmony_ci If measurement of the carrier frequency was enabled with 1158c2ecf20Sopenharmony_ci :ref:`lirc_set_measure_carrier_mode` then this packet gives you 1168c2ecf20Sopenharmony_ci the carrier frequency in Hertz. 1178c2ecf20Sopenharmony_ci 1188c2ecf20Sopenharmony_ci ``LIRC_MODE2_TIMEOUT`` 1198c2ecf20Sopenharmony_ci 1208c2ecf20Sopenharmony_ci If timeout reports are enabled with 1218c2ecf20Sopenharmony_ci :ref:`lirc_set_rec_timeout_reports`, when the timeout set with 1228c2ecf20Sopenharmony_ci :ref:`lirc_set_rec_timeout` expires due to no IR being detected, 1238c2ecf20Sopenharmony_ci this packet will be sent, with the number of microseconds with 1248c2ecf20Sopenharmony_ci no IR. 1258c2ecf20Sopenharmony_ci 1268c2ecf20Sopenharmony_ci.. _lirc-mode-pulse: 1278c2ecf20Sopenharmony_ci 1288c2ecf20Sopenharmony_ci``LIRC_MODE_PULSE`` 1298c2ecf20Sopenharmony_ci 1308c2ecf20Sopenharmony_ci In pulse mode, a sequence of pulse/space integer values are written to the 1318c2ecf20Sopenharmony_ci lirc device using :ref:`lirc-write`. 1328c2ecf20Sopenharmony_ci 1338c2ecf20Sopenharmony_ci The values are alternating pulse and space lengths, in microseconds. The 1348c2ecf20Sopenharmony_ci first and last entry must be a pulse, so there must be an odd number 1358c2ecf20Sopenharmony_ci of entries. 1368c2ecf20Sopenharmony_ci 1378c2ecf20Sopenharmony_ci This mode is used only for IR send. 1388c2ecf20Sopenharmony_ci 1398c2ecf20Sopenharmony_ci******************** 1408c2ecf20Sopenharmony_ciBPF based IR decoder 1418c2ecf20Sopenharmony_ci******************** 1428c2ecf20Sopenharmony_ci 1438c2ecf20Sopenharmony_ciThe kernel has support for decoding the most common 1448c2ecf20Sopenharmony_ci:ref:`IR protocols <Remote_controllers_Protocols>`, but there 1458c2ecf20Sopenharmony_ciare many protocols which are not supported. To support these, it is possible 1468c2ecf20Sopenharmony_cito load an BPF program which does the decoding. This can only be done on 1478c2ecf20Sopenharmony_ciLIRC devices which support reading raw IR. 1488c2ecf20Sopenharmony_ci 1498c2ecf20Sopenharmony_ciFirst, using the `bpf(2)`_ syscall with the ``BPF_LOAD_PROG`` argument, 1508c2ecf20Sopenharmony_ciprogram must be loaded of type ``BPF_PROG_TYPE_LIRC_MODE2``. Once attached 1518c2ecf20Sopenharmony_cito the LIRC device, this program will be called for each pulse, space or 1528c2ecf20Sopenharmony_citimeout event on the LIRC device. The context for the BPF program is a 1538c2ecf20Sopenharmony_cipointer to a unsigned int, which is a :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>` 1548c2ecf20Sopenharmony_civalue. When the program has decoded the scancode, it can be submitted using 1558c2ecf20Sopenharmony_cithe BPF functions ``bpf_rc_keydown()`` or ``bpf_rc_repeat()``. Mouse or pointer 1568c2ecf20Sopenharmony_cimovements can be reported using ``bpf_rc_pointer_rel()``. 1578c2ecf20Sopenharmony_ci 1588c2ecf20Sopenharmony_ciOnce you have the file descriptor for the ``BPF_PROG_TYPE_LIRC_MODE2`` BPF 1598c2ecf20Sopenharmony_ciprogram, it can be attached to the LIRC device using the `bpf(2)`_ syscall. 1608c2ecf20Sopenharmony_ciThe target must be the file descriptor for the LIRC device, and the 1618c2ecf20Sopenharmony_ciattach type must be ``BPF_LIRC_MODE2``. No more than 64 BPF programs can be 1628c2ecf20Sopenharmony_ciattached to a single LIRC device at a time. 1638c2ecf20Sopenharmony_ci 1648c2ecf20Sopenharmony_ci.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html 165