From 4195086571d49e6ad63087621d397c4a9eddd152 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 6 Feb 2014 10:08:57 -0200 Subject: [PATCH] [media] DocBook: Add a description for the Remote Controller interface Adds a missing section to describe the remote controller interface. The DocBook is just addin the same documentation as written at Documentation/ABI/testing/sysfs-class-rc, using the DocBook's way, and dropping timestamps/contact info. While that means that we'll have the same info on two parts, there are parts of the remote controller interface that doesn't belong at Documentation/ABI/, and it makes sense to have everything on the same place. This also means that we'll need to manually track to be sure that both places will be synchronized, but, as it is not expected much changes on it, this sync can be done manually. It also adds an introduction that states that the IR is a normal evdev/input interface, plus the sysfs class nodes. Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/remote_controllers.xml | 98 ++++++++++++++++++- 1 file changed, 97 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/remote_controllers.xml b/Documentation/DocBook/media/v4l/remote_controllers.xml index 18288a3c595b..c440a81f14c0 100644 --- a/Documentation/DocBook/media/v4l/remote_controllers.xml +++ b/Documentation/DocBook/media/v4l/remote_controllers.xml @@ -16,7 +16,13 @@ -1.0.0 +3.15 +2014-02-06 +mcc +Added the interface description and the RC sysfs class description. + + +1.0 2009-09-06 mcc Initial revision @@ -35,6 +41,96 @@ Currently, most analog and digital devices have a Infrared input for remote controllers. Each manufacturer has their own type of control. It is not rare for the same manufacturer to ship different types of controls, depending on the device. +A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse. +So, it uses all ioctls already defined for any other input devices. +However, remove controllers are more flexible than a normal input device, as the IR +receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes. +In order to allow flexibility, the Remote Controller subsystem allows controlling the +RC-specific attributes via the sysfs class nodes. + + +
+Remote Controller's sysfs nodes +As defined at Documentation/ABI/testing/sysfs-class-rc, those are the sysfs nodes that control the Remote Controllers: + +
+/sys/class/rc/ +The /sys/class/rc/ class sub-directory belongs to the Remote Controller +core and provides a sysfs interface for configuring infrared remote controller receivers. + + +
+
+/sys/class/rc/rcN/ +A /sys/class/rc/rcN directory is created for each remote + control receiver device where N is the number of the receiver. + +
+
+/sys/class/rc/rcN/protocols +Reading this file returns a list of available protocols, something like: +rc5 [rc6] nec jvc [sony] +Enabled protocols are shown in [] brackets. +Writing "+proto" will add a protocol to the list of enabled protocols. +Writing "-proto" will remove a protocol from the list of enabled protocols. +Writing "proto" will enable only "proto". +Writing "none" will disable all protocols. +Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used. + +
+
+/sys/class/rc/rcN/filter +Sets the scancode filter expected value. +Use in combination with /sys/class/rc/rcN/filter_mask to set the +expected value of the bits set in the filter mask. +If the hardware supports it then scancodes which do not match +the filter will be ignored. Otherwise the write will fail with +an error. +This value may be reset to 0 if the current protocol is altered. + +
+
+/sys/class/rc/rcN/filter_mask +Sets the scancode filter mask of bits to compare. +Use in combination with /sys/class/rc/rcN/filter to set the bits +of the scancode which should be compared against the expected +value. A value of 0 disables the filter to allow all valid +scancodes to be processed. +If the hardware supports it then scancodes which do not match +the filter will be ignored. Otherwise the write will fail with +an error. +This value may be reset to 0 if the current protocol is altered. + +
+
+/sys/class/rc/rcN/wakeup_filter +Sets the scancode wakeup filter expected value. +Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to +set the expected value of the bits set in the wakeup filter mask +to trigger a system wake event. +If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. +suspend to RAM or power off. +Otherwise the write will fail with an error. +This value may be reset to 0 if the current protocol is altered. + +
+
+/sys/class/rc/rcN/wakeup_filter_mask +Sets the scancode wakeup filter mask of bits to compare. +Use in combination with /sys/class/rc/rcN/wakeup_filter to set +the bits of the scancode which should be compared against the +expected value to trigger a system wake event. +If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. +suspend to RAM or power off. +Otherwise the write will fail with an error. +This value may be reset to 0 if the current protocol is altered. +
+
+ +
+Remote controller tables Unfortunately, for several years, there was no effort to create uniform IR keycodes for different devices. This caused the same IR keyname to be mapped completely differently on different IR devices. This resulted that the same IR keyname to be mapped completely different on -- 2.20.1