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