kernel.git/drivers/media/rc/rc-loopback.c, branch linux-4.13.y

[media] rc-main: assign driver type during allocation

2017-01-30T15:59:57Z

The driver type can be assigned immediately when an RC device requests to the framework to allocate the device. This is an 'enum rc_driver_type' data type and specifies whether the device is a raw receiver or scancode receiver. The type will be given as parameter to the rc_allocate_device device. Change accordingly all the drivers calling rc_allocate_device() so that the device type is specified during the rc device allocation. Whenever the device type is not specified, it will be set as RC_DRIVER_SCANCODE which was the default '0' value. Suggested-by: Sean Young Signed-off-by: Andi Shyti Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

[media] rc: rc-loopback: Add loopback of filter scancodes

2017-01-30T15:56:21Z

Add the s_wakeup_filter callback to the rc-loopback driver, which instead of setting the filter just feeds the scancode back through the input device so that it can be verified. Signed-off-by: James Hogan Signed-off-by: Antti Seppälä Signed-off-by: Sean Young Cc: David Härdeman Signed-off-by: Mauro Carvalho Chehab

[media] rc: raw IR drivers cannot handle cec, unknown or other

2017-01-30T14:40:50Z

unknown and other are for IR protocols for which we have no decoder, so the raw IR drivers have no chance of generating them. cec is not an IR protocol. Signed-off-by: Sean Young Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: Bruno Prémont Signed-off-by: Mauro Carvalho Chehab

[media] media: Drop FSF's postal address from the source code files

2017-01-27T13:38:09Z

Drop the FSF's postal address from the source code files that typically contain mostly the license text. Of the 628 removed instances, 578 are outdated. The patch has been created with the following command without manual edits: git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \ drivers/media/ include/media|while read i; do i=$i perl -e ' open(F,"< $ENV{i}"); $a=join("", ); $a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m && $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, $2\n$1/m; close(F); open(F, "> $ENV{i}"); print F $a; close(F);'; done Signed-off-by: Sakari Ailus

Revert "[media] rc: rc-loopback: Add loopback of filter scancodes"

2015-08-19T10:02:53Z

This reverts commit 2e4ebde269236da2a41183522127715b6d9d80ce. The current code is not mature enough, the API should allow a single protocol to be specified. Also, the current code contains heuristics that will depend on module load order. Signed-off-by: David Härdeman Acked-by: Antti Seppälä Signed-off-by: Mauro Carvalho Chehab

[media] rc: rc-loopback: Add loopback of filter scancodes

2015-05-14T17:35:59Z

Add the s_wakeup_filter callback to the rc-loopback driver, which instead of setting the filter just feeds the scancode back through the input device so that it can be verified. Signed-off-by: James Hogan Signed-off-by: Antti Seppälä Cc: David Härdeman Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: remove protocol arrays

2014-07-25T22:10:43Z

The basic API of rc-core used to be: dev = rc_allocate_device(); dev->x = a; dev->y = b; dev->z = c; rc_register_device(); which is a pretty common pattern in the kernel, after the introduction of protocol arrays the API looks something like: dev = rc_allocate_device(); dev->x = a; rc_set_allowed_protocols(dev, RC_BIT_X); dev->z = c; rc_register_device(); There's no real need for the protocols to be an array, so change it back to be consistent (and in preparation for the following patches). [m.chehab@samsung.com: added missing changes at some files] Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab

[media] rc: abstract access to allowed/enabled protocols

2014-03-11T16:24:39Z

The allowed and enabled protocol masks need to be expanded to be per filter type in order to support wakeup filter protocol selection. To ease that process abstract access to the rc_dev::allowed_protos and rc_dev::enabled_protocols members with inline functions. Signed-off-by: James Hogan Reviewed-by: Antti Seppälä Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: add separate defines for protocol bitmaps and numbers

2012-10-27T13:49:51Z

The RC_TYPE_* defines are currently used both where a single protocol is expected and where a bitmap of protocols is expected. Functions like rc_keydown() and functions which add/remove entries to the keytable want a single protocol. Future userspace APIs would also benefit from numeric protocols (rather than bitmap ones). Keytables are smaller if they can use a small(ish) integer rather than a bitmap. Other functions or struct members (e.g. allowed_protos, enabled_protocols, etc) accept multiple protocols and need a bitmap. Using different types reduces the risk of programmer error. Using a protocol enum whereever possible also makes for a more future-proof user-space API as we don't need to worry about a sufficient number of bits being available (e.g. in structs used for ioctl() calls). The use of both a number and a corresponding bit is dalso one in e.g. the input subsystem as well (see all the references to set/clear bit when changing keytables for example). This patch separate the different usages in preparation for upcoming patches. Where a single protocol is expected, enum rc_type is used; where one or more protocol(s) are expected, something like u64 is used. The patch has been rewritten so that the format of the sysfs "protocols" file is no longer altered (at the loss of some detail). The file itself should probably be deprecated in the future though. Signed-off-by: David Härdeman Cc: Andy Walls Cc: Maxim Levitsky Cc: Antti Palosaari Cc: Mike Isely Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: move timeout and checks to lirc

2012-08-13T22:59:41Z

The lirc TX functionality expects the process which writes (TX) data to the lirc dev to sleep until the actual data has been transmitted by the hardware. Since the same timeout calculation is duplicated in more than one driver (and would have to be duplicated in even more drivers as they gain TX support), it makes sense to move this timeout calculation to the lirc layer instead. At the same time, centralize some of the sanity checks. Signed-off-by: David Härdeman Cc: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab