xref: /OK3568_Linux_fs/kernel/Documentation/driver-api/media/rc-core.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun.. SPDX-License-Identifier: GPL-2.0
2*4882a593Smuzhiyun
3*4882a593SmuzhiyunRemote Controller devices
4*4882a593Smuzhiyun-------------------------
5*4882a593Smuzhiyun
6*4882a593SmuzhiyunRemote Controller core
7*4882a593Smuzhiyun~~~~~~~~~~~~~~~~~~~~~~
8*4882a593Smuzhiyun
9*4882a593SmuzhiyunThe remote controller core implements infrastructure to receive and send
10*4882a593Smuzhiyunremote controller keyboard keystrokes and mouse events.
11*4882a593Smuzhiyun
12*4882a593SmuzhiyunEvery time a key is pressed on a remote controller, a scan code is produced.
13*4882a593SmuzhiyunAlso, on most hardware, keeping a key pressed for more than a few dozens of
14*4882a593Smuzhiyunmilliseconds produce a repeat key event. That's somewhat similar to what
15*4882a593Smuzhiyuna normal keyboard or mouse is handled internally on Linux\ [#f1]_. So, the
16*4882a593Smuzhiyunremote controller core is implemented on the top of the linux input/evdev
17*4882a593Smuzhiyuninterface.
18*4882a593Smuzhiyun
19*4882a593Smuzhiyun.. [#f1]
20*4882a593Smuzhiyun
21*4882a593Smuzhiyun   The main difference is that, on keyboard events, the keyboard controller
22*4882a593Smuzhiyun   produces one event for a key press and another one for key release. On
23*4882a593Smuzhiyun   infrared-based remote controllers, there's no key release event. Instead,
24*4882a593Smuzhiyun   an extra code is produced to indicate key repeats.
25*4882a593Smuzhiyun
26*4882a593SmuzhiyunHowever, most of the remote controllers use infrared (IR) to transmit signals.
27*4882a593SmuzhiyunAs there are several protocols used to modulate infrared signals, one
28*4882a593Smuzhiyunimportant part of the core is dedicated to adjust the driver and the core
29*4882a593Smuzhiyunsystem to support the infrared protocol used by the emitter.
30*4882a593Smuzhiyun
31*4882a593SmuzhiyunThe infrared transmission is done by blinking a infrared emitter using a
32*4882a593Smuzhiyuncarrier. The carrier can be switched on or off by the IR transmitter
33*4882a593Smuzhiyunhardware. When the carrier is switched on, it is called *PULSE*.
34*4882a593SmuzhiyunWhen the carrier is switched off, it is called *SPACE*.
35*4882a593Smuzhiyun
36*4882a593SmuzhiyunIn other words, a typical IR transmission can be viewed as a sequence of
37*4882a593Smuzhiyun*PULSE* and *SPACE* events, each with a given duration.
38*4882a593Smuzhiyun
39*4882a593SmuzhiyunThe carrier parameters (frequency, duty cycle) and the intervals for
40*4882a593Smuzhiyun*PULSE* and *SPACE* events depend on the protocol.
41*4882a593SmuzhiyunFor example, the NEC protocol uses a carrier of 38kHz, and transmissions
42*4882a593Smuzhiyunstart with a 9ms *PULSE* and a 4.5ms SPACE. It then transmits 16 bits of
43*4882a593Smuzhiyunscan code, being 8 bits for address (usually it is a fixed number for a
44*4882a593Smuzhiyungiven remote controller), followed by 8 bits of code. A bit "1" is modulated
45*4882a593Smuzhiyunwith 560µs *PULSE* followed by 1690µs *SPACE* and a bit "0"  is modulated
46*4882a593Smuzhiyunwith 560µs *PULSE* followed by 560µs *SPACE*.
47*4882a593Smuzhiyun
48*4882a593SmuzhiyunAt receiver, a simple low-pass filter can be used to convert the received
49*4882a593Smuzhiyunsignal in a sequence of *PULSE/SPACE* events, filtering out the carrier
50*4882a593Smuzhiyunfrequency. Due to that, the receiver doesn't care about the carrier's
51*4882a593Smuzhiyunactual frequency parameters: all it has to do is to measure the amount
52*4882a593Smuzhiyunof time it receives *PULSE/SPACE* events.
53*4882a593SmuzhiyunSo, a simple IR receiver hardware will just provide a sequence of timings
54*4882a593Smuzhiyunfor those events to the Kernel. The drivers for hardware with such kind of
55*4882a593Smuzhiyunreceivers are identified by  ``RC_DRIVER_IR_RAW``, as defined by
56*4882a593Smuzhiyun:c:type:`rc_driver_type`\ [#f2]_. Other hardware come with a
57*4882a593Smuzhiyunmicrocontroller that decode the *PULSE/SPACE* sequence and return scan
58*4882a593Smuzhiyuncodes to the Kernel. Such kind of receivers are identified
59*4882a593Smuzhiyunby ``RC_DRIVER_SCANCODE``.
60*4882a593Smuzhiyun
61*4882a593Smuzhiyun.. [#f2]
62*4882a593Smuzhiyun
63*4882a593Smuzhiyun   The RC core also supports devices that have just IR emitters,
64*4882a593Smuzhiyun   without any receivers. Right now, all such devices work only in
65*4882a593Smuzhiyun   raw TX mode. Such kind of hardware is identified as
66*4882a593Smuzhiyun   ``RC_DRIVER_IR_RAW_TX``.
67*4882a593Smuzhiyun
68*4882a593SmuzhiyunWhen the RC core receives events produced by ``RC_DRIVER_IR_RAW`` IR
69*4882a593Smuzhiyunreceivers, it needs to decode the IR protocol, in order to obtain the
70*4882a593Smuzhiyuncorresponding scan code. The protocols supported by the RC core are
71*4882a593Smuzhiyundefined at enum :c:type:`rc_proto`.
72*4882a593Smuzhiyun
73*4882a593SmuzhiyunWhen the RC code receives a scan code (either directly, by a driver
74*4882a593Smuzhiyunof the type ``RC_DRIVER_SCANCODE``, or via its IR decoders), it needs
75*4882a593Smuzhiyunto convert into a Linux input event code. This is done via a mapping
76*4882a593Smuzhiyuntable.
77*4882a593Smuzhiyun
78*4882a593SmuzhiyunThe Kernel has support for mapping tables available on most media
79*4882a593Smuzhiyundevices. It also supports loading a table in runtime, via some
80*4882a593Smuzhiyunsysfs nodes. See the :ref:`RC userspace API <Remote_controllers_Intro>`
81*4882a593Smuzhiyunfor more details.
82*4882a593Smuzhiyun
83*4882a593SmuzhiyunRemote controller data structures and functions
84*4882a593Smuzhiyun^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
85*4882a593Smuzhiyun
86*4882a593Smuzhiyun.. kernel-doc:: include/media/rc-core.h
87*4882a593Smuzhiyun
88*4882a593Smuzhiyun.. kernel-doc:: include/media/rc-map.h
89