From patchwork Thu Feb 6 14:31:19 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 3596391 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E976E9F2E9 for ; Thu, 6 Feb 2014 14:32:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CFBA5200F2 for ; Thu, 6 Feb 2014 14:32:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 024E120131 for ; Thu, 6 Feb 2014 14:32:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752293AbaBFOcP (ORCPT ); Thu, 6 Feb 2014 09:32:15 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:57674 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbaBFOcO (ORCPT ); Thu, 6 Feb 2014 09:32:14 -0500 Received: from [201.74.152.26] (helo=smtp.w2.samsung.com) by bombadil.infradead.org with esmtpsa (Exim 4.80.1 #2 (Red Hat Linux)) id 1WBPzv-0005t5-Vs; Thu, 06 Feb 2014 14:32:12 +0000 Received: from mchehab by smtp.w2.samsung.com with local (Exim 4.80.1) (envelope-from ) id 1WBPz6-0002OL-Dc; Thu, 06 Feb 2014 12:31:20 -0200 From: Mauro Carvalho Chehab Cc: Mauro Carvalho Chehab , Linux Media Mailing List , Mauro Carvalho Chehab Subject: [PATCH 2/2] [media] DocBook: Add a description for the Remote Controller interface Date: Thu, 6 Feb 2014 12:31:19 -0200 Message-Id: <1391697079-9156-2-git-send-email-m.chehab@samsung.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1391697079-9156-1-git-send-email-m.chehab@samsung.com> References: <1391697079-9156-1-git-send-email-m.chehab@samsung.com> To: unlisted-recipients:; (no To-header on input) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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