mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
88 lines
3.9 KiB
88 lines
3.9 KiB
.. SPDX-License-Identifier: GPL-2.0 |
|
|
|
Remote Controller devices |
|
------------------------- |
|
|
|
Remote Controller core |
|
~~~~~~~~~~~~~~~~~~~~~~ |
|
|
|
The remote controller core implements infrastructure to receive and send |
|
remote controller keyboard keystrokes and mouse events. |
|
|
|
Every time a key is pressed on a remote controller, a scan code is produced. |
|
Also, on most hardware, keeping a key pressed for more than a few dozens of |
|
milliseconds produce a repeat key event. That's somewhat similar to what |
|
a normal keyboard or mouse is handled internally on Linux\ [#f1]_. So, the |
|
remote controller core is implemented on the top of the linux input/evdev |
|
interface. |
|
|
|
.. [#f1] |
|
|
|
The main difference is that, on keyboard events, the keyboard controller |
|
produces one event for a key press and another one for key release. On |
|
infrared-based remote controllers, there's no key release event. Instead, |
|
an extra code is produced to indicate key repeats. |
|
|
|
However, most of the remote controllers use infrared (IR) to transmit signals. |
|
As there are several protocols used to modulate infrared signals, one |
|
important part of the core is dedicated to adjust the driver and the core |
|
system to support the infrared protocol used by the emitter. |
|
|
|
The infrared transmission is done by blinking a infrared emitter using a |
|
carrier. The carrier can be switched on or off by the IR transmitter |
|
hardware. When the carrier is switched on, it is called *PULSE*. |
|
When the carrier is switched off, it is called *SPACE*. |
|
|
|
In other words, a typical IR transmission can be viewed as a sequence of |
|
*PULSE* and *SPACE* events, each with a given duration. |
|
|
|
The carrier parameters (frequency, duty cycle) and the intervals for |
|
*PULSE* and *SPACE* events depend on the protocol. |
|
For example, the NEC protocol uses a carrier of 38kHz, and transmissions |
|
start with a 9ms *PULSE* and a 4.5ms SPACE. It then transmits 16 bits of |
|
scan code, being 8 bits for address (usually it is a fixed number for a |
|
given remote controller), followed by 8 bits of code. A bit "1" is modulated |
|
with 560µs *PULSE* followed by 1690µs *SPACE* and a bit "0" is modulated |
|
with 560µs *PULSE* followed by 560µs *SPACE*. |
|
|
|
At receiver, a simple low-pass filter can be used to convert the received |
|
signal in a sequence of *PULSE/SPACE* events, filtering out the carrier |
|
frequency. Due to that, the receiver doesn't care about the carrier's |
|
actual frequency parameters: all it has to do is to measure the amount |
|
of time it receives *PULSE/SPACE* events. |
|
So, a simple IR receiver hardware will just provide a sequence of timings |
|
for those events to the Kernel. The drivers for hardware with such kind of |
|
receivers are identified by ``RC_DRIVER_IR_RAW``, as defined by |
|
:c:type:`rc_driver_type`\ [#f2]_. Other hardware come with a |
|
microcontroller that decode the *PULSE/SPACE* sequence and return scan |
|
codes to the Kernel. Such kind of receivers are identified |
|
by ``RC_DRIVER_SCANCODE``. |
|
|
|
.. [#f2] |
|
|
|
The RC core also supports devices that have just IR emitters, |
|
without any receivers. Right now, all such devices work only in |
|
raw TX mode. Such kind of hardware is identified as |
|
``RC_DRIVER_IR_RAW_TX``. |
|
|
|
When the RC core receives events produced by ``RC_DRIVER_IR_RAW`` IR |
|
receivers, it needs to decode the IR protocol, in order to obtain the |
|
corresponding scan code. The protocols supported by the RC core are |
|
defined at enum :c:type:`rc_proto`. |
|
|
|
When the RC code receives a scan code (either directly, by a driver |
|
of the type ``RC_DRIVER_SCANCODE``, or via its IR decoders), it needs |
|
to convert into a Linux input event code. This is done via a mapping |
|
table. |
|
|
|
The Kernel has support for mapping tables available on most media |
|
devices. It also supports loading a table in runtime, via some |
|
sysfs nodes. See the :ref:`RC userspace API <Remote_controllers_Intro>` |
|
for more details. |
|
|
|
Remote controller data structures and functions |
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
|
|
.. kernel-doc:: include/media/rc-core.h |
|
|
|
.. kernel-doc:: include/media/rc-map.h
|
|
|