xref: /OK3568_Linux_fs/kernel/Documentation/userspace-api/media/rc/lirc-dev-intro.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
2*4882a593Smuzhiyun
3*4882a593Smuzhiyun.. _lirc_dev_intro:
4*4882a593Smuzhiyun
5*4882a593Smuzhiyun************
6*4882a593SmuzhiyunIntroduction
7*4882a593Smuzhiyun************
8*4882a593Smuzhiyun
9*4882a593SmuzhiyunLIRC stands for Linux Infrared Remote Control. The LIRC device interface is
10*4882a593Smuzhiyuna bi-directional interface for transporting raw IR and decoded scancodes
11*4882a593Smuzhiyundata between userspace and kernelspace. Fundamentally, it is just a chardev
12*4882a593Smuzhiyun(/dev/lircX, for X = 0, 1, 2, ...), with a number of standard struct
13*4882a593Smuzhiyunfile_operations defined on it. With respect to transporting raw IR and
14*4882a593Smuzhiyundecoded scancodes to and fro, the essential fops are read, write and ioctl.
15*4882a593Smuzhiyun
16*4882a593SmuzhiyunIt is also possible to attach a BPF program to a LIRC device for decoding
17*4882a593Smuzhiyunraw IR into scancodes.
18*4882a593Smuzhiyun
19*4882a593SmuzhiyunExample dmesg output upon a driver registering w/LIRC:
20*4882a593Smuzhiyun
21*4882a593Smuzhiyun.. code-block:: none
22*4882a593Smuzhiyun
23*4882a593Smuzhiyun    $ dmesg |grep lirc_dev
24*4882a593Smuzhiyun    rc rc0: lirc_dev: driver mceusb registered at minor = 0, raw IR receiver, raw IR transmitter
25*4882a593Smuzhiyun
26*4882a593SmuzhiyunWhat you should see for a chardev:
27*4882a593Smuzhiyun
28*4882a593Smuzhiyun.. code-block:: none
29*4882a593Smuzhiyun
30*4882a593Smuzhiyun    $ ls -l /dev/lirc*
31*4882a593Smuzhiyun    crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0
32*4882a593Smuzhiyun
33*4882a593SmuzhiyunNote that the package `v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_
34*4882a593Smuzhiyuncontains tools for working with LIRC devices:
35*4882a593Smuzhiyun
36*4882a593Smuzhiyun - ir-ctl: can receive raw IR and transmit IR, as well as query LIRC
37*4882a593Smuzhiyun   device features.
38*4882a593Smuzhiyun
39*4882a593Smuzhiyun - ir-keytable: can load keymaps; allows you to set IR kernel protocols; load
40*4882a593Smuzhiyun   BPF IR decoders and test IR decoding. Some BPF IR decoders are also
41*4882a593Smuzhiyun   provided.
42*4882a593Smuzhiyun
43*4882a593Smuzhiyun.. _lirc_modes:
44*4882a593Smuzhiyun
45*4882a593Smuzhiyun**********
46*4882a593SmuzhiyunLIRC modes
47*4882a593Smuzhiyun**********
48*4882a593Smuzhiyun
49*4882a593SmuzhiyunLIRC supports some modes of receiving and sending IR codes, as shown
50*4882a593Smuzhiyunon the following table.
51*4882a593Smuzhiyun
52*4882a593Smuzhiyun.. _lirc-mode-scancode:
53*4882a593Smuzhiyun.. _lirc-scancode-flag-toggle:
54*4882a593Smuzhiyun.. _lirc-scancode-flag-repeat:
55*4882a593Smuzhiyun
56*4882a593Smuzhiyun``LIRC_MODE_SCANCODE``
57*4882a593Smuzhiyun
58*4882a593Smuzhiyun    This mode is for both sending and receiving IR.
59*4882a593Smuzhiyun
60*4882a593Smuzhiyun    For transmitting (aka sending), create a ``struct lirc_scancode`` with
61*4882a593Smuzhiyun    the desired scancode set in the ``scancode`` member, :c:type:`rc_proto`
62*4882a593Smuzhiyun    set to the :ref:`IR protocol <Remote_controllers_Protocols>`, and all other
63*4882a593Smuzhiyun    members set to 0. Write this struct to the lirc device.
64*4882a593Smuzhiyun
65*4882a593Smuzhiyun    For receiving, you read ``struct lirc_scancode`` from the LIRC device.
66*4882a593Smuzhiyun    The ``scancode`` field is set to the received scancode and the
67*4882a593Smuzhiyun    :ref:`IR protocol <Remote_controllers_Protocols>` is set in
68*4882a593Smuzhiyun    :c:type:`rc_proto`. If the scancode maps to a valid key code, this is set
69*4882a593Smuzhiyun    in the ``keycode`` field, else it is set to ``KEY_RESERVED``.
70*4882a593Smuzhiyun
71*4882a593Smuzhiyun    The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set if the toggle
72*4882a593Smuzhiyun    bit is set in protocols that support it (e.g. rc-5 and rc-6), or
73*4882a593Smuzhiyun    ``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for protocols
74*4882a593Smuzhiyun    that support it (e.g. nec).
75*4882a593Smuzhiyun
76*4882a593Smuzhiyun    In the Sanyo and NEC protocol, if you hold a button on remote, rather than
77*4882a593Smuzhiyun    repeating the entire scancode, the remote sends a shorter message with
78*4882a593Smuzhiyun    no scancode, which just means button is held, a "repeat". When this is
79*4882a593Smuzhiyun    received, the ``LIRC_SCANCODE_FLAG_REPEAT`` is set and the scancode and
80*4882a593Smuzhiyun    keycode is repeated.
81*4882a593Smuzhiyun
82*4882a593Smuzhiyun    With nec, there is no way to distinguish "button hold" from "repeatedly
83*4882a593Smuzhiyun    pressing the same button". The rc-5 and rc-6 protocols have a toggle bit.
84*4882a593Smuzhiyun    When a button is released and pressed again, the toggle bit is inverted.
85*4882a593Smuzhiyun    If the toggle bit is set, the ``LIRC_SCANCODE_FLAG_TOGGLE`` is set.
86*4882a593Smuzhiyun
87*4882a593Smuzhiyun    The ``timestamp`` field is filled with the time nanoseconds
88*4882a593Smuzhiyun    (in ``CLOCK_MONOTONIC``) when the scancode was decoded.
89*4882a593Smuzhiyun
90*4882a593Smuzhiyun.. _lirc-mode-mode2:
91*4882a593Smuzhiyun
92*4882a593Smuzhiyun``LIRC_MODE_MODE2``
93*4882a593Smuzhiyun
94*4882a593Smuzhiyun    The driver returns a sequence of pulse and space codes to userspace,
95*4882a593Smuzhiyun    as a series of u32 values.
96*4882a593Smuzhiyun
97*4882a593Smuzhiyun    This mode is used only for IR receive.
98*4882a593Smuzhiyun
99*4882a593Smuzhiyun    The upper 8 bits determine the packet type, and the lower 24 bits
100*4882a593Smuzhiyun    the payload. Use ``LIRC_VALUE()`` macro to get the payload, and
101*4882a593Smuzhiyun    the macro ``LIRC_MODE2()`` will give you the type, which
102*4882a593Smuzhiyun    is one of:
103*4882a593Smuzhiyun
104*4882a593Smuzhiyun    ``LIRC_MODE2_PULSE``
105*4882a593Smuzhiyun
106*4882a593Smuzhiyun        Signifies the presence of IR in microseconds.
107*4882a593Smuzhiyun
108*4882a593Smuzhiyun    ``LIRC_MODE2_SPACE``
109*4882a593Smuzhiyun
110*4882a593Smuzhiyun        Signifies absence of IR in microseconds.
111*4882a593Smuzhiyun
112*4882a593Smuzhiyun    ``LIRC_MODE2_FREQUENCY``
113*4882a593Smuzhiyun
114*4882a593Smuzhiyun        If measurement of the carrier frequency was enabled with
115*4882a593Smuzhiyun        :ref:`lirc_set_measure_carrier_mode` then this packet gives you
116*4882a593Smuzhiyun        the carrier frequency in Hertz.
117*4882a593Smuzhiyun
118*4882a593Smuzhiyun    ``LIRC_MODE2_TIMEOUT``
119*4882a593Smuzhiyun
120*4882a593Smuzhiyun        If timeout reports are enabled with
121*4882a593Smuzhiyun        :ref:`lirc_set_rec_timeout_reports`, when the timeout set with
122*4882a593Smuzhiyun        :ref:`lirc_set_rec_timeout` expires due to no IR being detected,
123*4882a593Smuzhiyun        this packet will be sent, with the number of microseconds with
124*4882a593Smuzhiyun        no IR.
125*4882a593Smuzhiyun
126*4882a593Smuzhiyun.. _lirc-mode-pulse:
127*4882a593Smuzhiyun
128*4882a593Smuzhiyun``LIRC_MODE_PULSE``
129*4882a593Smuzhiyun
130*4882a593Smuzhiyun    In pulse mode, a sequence of pulse/space integer values are written to the
131*4882a593Smuzhiyun    lirc device using :ref:`lirc-write`.
132*4882a593Smuzhiyun
133*4882a593Smuzhiyun    The values are alternating pulse and space lengths, in microseconds. The
134*4882a593Smuzhiyun    first and last entry must be a pulse, so there must be an odd number
135*4882a593Smuzhiyun    of entries.
136*4882a593Smuzhiyun
137*4882a593Smuzhiyun    This mode is used only for IR send.
138*4882a593Smuzhiyun
139*4882a593Smuzhiyun********************
140*4882a593SmuzhiyunBPF based IR decoder
141*4882a593Smuzhiyun********************
142*4882a593Smuzhiyun
143*4882a593SmuzhiyunThe kernel has support for decoding the most common
144*4882a593Smuzhiyun:ref:`IR protocols <Remote_controllers_Protocols>`, but there
145*4882a593Smuzhiyunare many protocols which are not supported. To support these, it is possible
146*4882a593Smuzhiyunto load an BPF program which does the decoding. This can only be done on
147*4882a593SmuzhiyunLIRC devices which support reading raw IR.
148*4882a593Smuzhiyun
149*4882a593SmuzhiyunFirst, using the `bpf(2)`_ syscall with the ``BPF_LOAD_PROG`` argument,
150*4882a593Smuzhiyunprogram must be loaded of type ``BPF_PROG_TYPE_LIRC_MODE2``. Once attached
151*4882a593Smuzhiyunto the LIRC device, this program will be called for each pulse, space or
152*4882a593Smuzhiyuntimeout event on the LIRC device. The context for the BPF program is a
153*4882a593Smuzhiyunpointer to a unsigned int, which is a :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>`
154*4882a593Smuzhiyunvalue. When the program has decoded the scancode, it can be submitted using
155*4882a593Smuzhiyunthe BPF functions ``bpf_rc_keydown()`` or ``bpf_rc_repeat()``. Mouse or pointer
156*4882a593Smuzhiyunmovements can be reported using ``bpf_rc_pointer_rel()``.
157*4882a593Smuzhiyun
158*4882a593SmuzhiyunOnce you have the file descriptor for the ``BPF_PROG_TYPE_LIRC_MODE2`` BPF
159*4882a593Smuzhiyunprogram, it can be attached to the LIRC device using the `bpf(2)`_ syscall.
160*4882a593SmuzhiyunThe target must be the file descriptor for the LIRC device, and the
161*4882a593Smuzhiyunattach type must be ``BPF_LIRC_MODE2``. No more than 64 BPF programs can be
162*4882a593Smuzhiyunattached to a single LIRC device at a time.
163*4882a593Smuzhiyun
164*4882a593Smuzhiyun.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
165