p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
linux_old1/include/media/rc-map.h

221 lines
10 KiB
C
Raw Normal View History

V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
/*
* rc-map.h - define RC map names used by RC drivers
*
[media, edac] Change my email address There are several left overs with my old email address. Remove their occurrences and add myself at CREDITS, to allow people to be able to reach me on my new addresses. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-07 18:03:07 +08:00
* Copyright (c) 2010 by Mauro Carvalho Chehab
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
#include <linux/input.h>
[media] rc-core: add separate defines for protocol bitmaps and numbers 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 <david@hardeman.nu> Cc: Andy Walls <awalls@md.metrocast.net> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Antti Palosaari <crope@iki.fi> Cc: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-12 06:11:54 +08:00
enum rc_type {
RC_TYPE_UNKNOWN = 0, /* Protocol not known */
RC_TYPE_OTHER = 1, /* Protocol known but proprietary */
[media] rc-core: remove the LIRC "protocol" The LIRC protocol was always a bad fit and if we're ever going to expose protocol numbers in a user-space API, it'd be better to get rid of the LIRC "protocol" first. The sysfs API is kept backwards compatible by always listing the lirc protocol as present and enabled. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-05-20 06:03:22 +08:00
RC_TYPE_RC5 = 2, /* Philips RC5 protocol */
RC_TYPE_RC5X = 3, /* Philips RC5x protocol */
RC_TYPE_RC5_SZ = 4, /* StreamZap variant of RC5 */
RC_TYPE_JVC = 5, /* JVC protocol */
RC_TYPE_SONY12 = 6, /* Sony 12 bit protocol */
RC_TYPE_SONY15 = 7, /* Sony 15 bit protocol */
RC_TYPE_SONY20 = 8, /* Sony 20 bit protocol */
RC_TYPE_NEC = 9, /* NEC protocol */
RC_TYPE_SANYO = 10, /* Sanyo protocol */
RC_TYPE_MCE_KBD = 11, /* RC6-ish MCE keyboard/mouse */
RC_TYPE_RC6_0 = 12, /* Philips RC6-0-16 protocol */
RC_TYPE_RC6_6A_20 = 13, /* Philips RC6-6A-20 protocol */
RC_TYPE_RC6_6A_24 = 14, /* Philips RC6-6A-24 protocol */
RC_TYPE_RC6_6A_32 = 15, /* Philips RC6-6A-32 protocol */
RC_TYPE_RC6_MCE = 16, /* MCE (Philips RC6-6A-32 subtype) protocol */
RC_TYPE_SHARP = 17, /* Sharp protocol */
RC_TYPE_XMP = 18, /* XMP protocol */
[media] rc-core: add separate defines for protocol bitmaps and numbers 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 <david@hardeman.nu> Cc: Andy Walls <awalls@md.metrocast.net> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Antti Palosaari <crope@iki.fi> Cc: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-12 06:11:54 +08:00
};
#define RC_BIT_NONE 0
#define RC_BIT_UNKNOWN (1 << RC_TYPE_UNKNOWN)
#define RC_BIT_OTHER (1 << RC_TYPE_OTHER)
#define RC_BIT_RC5 (1 << RC_TYPE_RC5)
#define RC_BIT_RC5X (1 << RC_TYPE_RC5X)
#define RC_BIT_RC5_SZ (1 << RC_TYPE_RC5_SZ)
#define RC_BIT_JVC (1 << RC_TYPE_JVC)
#define RC_BIT_SONY12 (1 << RC_TYPE_SONY12)
#define RC_BIT_SONY15 (1 << RC_TYPE_SONY15)
#define RC_BIT_SONY20 (1 << RC_TYPE_SONY20)
#define RC_BIT_NEC (1 << RC_TYPE_NEC)
#define RC_BIT_SANYO (1 << RC_TYPE_SANYO)
#define RC_BIT_MCE_KBD (1 << RC_TYPE_MCE_KBD)
#define RC_BIT_RC6_0 (1 << RC_TYPE_RC6_0)
#define RC_BIT_RC6_6A_20 (1 << RC_TYPE_RC6_6A_20)
#define RC_BIT_RC6_6A_24 (1 << RC_TYPE_RC6_6A_24)
#define RC_BIT_RC6_6A_32 (1 << RC_TYPE_RC6_6A_32)
#define RC_BIT_RC6_MCE (1 << RC_TYPE_RC6_MCE)
[media] media: rc: add Sharp infrared protocol Add Sharp infrared protocol constants RC_TYPE_SHARP and RC_BIT_SHARP. Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-01-17 21:58:47 +08:00
#define RC_BIT_SHARP (1 << RC_TYPE_SHARP)
[media] rc: Add support for decoding XMP protocol This protocol is found on Dreambox remotes [m.chehab@samsung.com: CodingStyle fixes and conflict fix] Signed-off-by: Marcel Mol <marcel@mesa.nl> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-07-27 04:28:26 +08:00
#define RC_BIT_XMP (1 << RC_TYPE_XMP)
[media] rc-core: add separate defines for protocol bitmaps and numbers 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 <david@hardeman.nu> Cc: Andy Walls <awalls@md.metrocast.net> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Antti Palosaari <crope@iki.fi> Cc: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-12 06:11:54 +08:00
[media] rc-core: remove the LIRC "protocol" The LIRC protocol was always a bad fit and if we're ever going to expose protocol numbers in a user-space API, it'd be better to get rid of the LIRC "protocol" first. The sysfs API is kept backwards compatible by always listing the lirc protocol as present and enabled. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-05-20 06:03:22 +08:00
#define RC_BIT_ALL (RC_BIT_UNKNOWN | RC_BIT_OTHER | \
[media] rc-core: add separate defines for protocol bitmaps and numbers 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 <david@hardeman.nu> Cc: Andy Walls <awalls@md.metrocast.net> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Antti Palosaari <crope@iki.fi> Cc: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-12 06:11:54 +08:00
RC_BIT_RC5 | RC_BIT_RC5X | RC_BIT_RC5_SZ | \
RC_BIT_JVC | \
RC_BIT_SONY12 | RC_BIT_SONY15 | RC_BIT_SONY20 | \
RC_BIT_NEC | RC_BIT_SANYO | RC_BIT_MCE_KBD | \
RC_BIT_RC6_0 | RC_BIT_RC6_6A_20 | RC_BIT_RC6_6A_24 | \
[media] rc: Add support for decoding XMP protocol This protocol is found on Dreambox remotes [m.chehab@samsung.com: CodingStyle fixes and conflict fix] Signed-off-by: Marcel Mol <marcel@mesa.nl> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-07-27 04:28:26 +08:00
RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE | RC_BIT_SHARP | \
RC_BIT_XMP)
V4L/DVB: IR: add RC6 keymap for Windows Media Center Ed. remotes This is the RC6 keymap for the Windows Media Center Edition remotes that come bundled with MCE/eHome Infrared Remote transceivers. Tested with 3 different variants of the remote, but its possible there are still some additional keys missing, but its simple enough to add them in later... This patch also adds an IR_TYPE_ALL convenience macro to make life easier for receivers that support all IR protocols. v2: fix an erroneous comment that referred to imon devices Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-06-02 04:30:35 +08:00
[media] rc-core: improve ir-kbd-i2c get_key functions The arguments used for ir-kbd-i2c's get_key() functions are not really suited for rc-core and the ir_raw/ir_key distinction is just confusing. Convert all of them to return a protocol/scancode/toggle triple instead. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-04-04 07:31:25 +08:00
#define RC_SCANCODE_UNKNOWN(x) (x)
#define RC_SCANCODE_OTHER(x) (x)
#define RC_SCANCODE_NEC(addr, cmd) (((addr) << 8) | (cmd))
#define RC_SCANCODE_NECX(addr, cmd) (((addr) << 8) | (cmd))
#define RC_SCANCODE_NEC32(data) ((data) & 0xffffffff)
#define RC_SCANCODE_RC5(sys, cmd) (((sys) << 8) | (cmd))
#define RC_SCANCODE_RC5_SZ(sys, cmd) (((sys) << 8) | (cmd))
#define RC_SCANCODE_RC6_0(sys, cmd) (((sys) << 8) | (cmd))
#define RC_SCANCODE_RC6_6A(vendor, sys, cmd) (((vendor) << 16) | ((sys) << 8) | (cmd))
[media] rc: Name RC keymap tables as rc_map_table Remote keytables had different names all over the place. Part of the fault is due to a bad naming when rc subsystem was created, but there were lots of old names that were still here. Use a common standard for everything. Patch generated by this script: for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode,rc_map_table,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_codes_,rc_map_,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_key_map,rc_map_table,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_map_table_size,rc_map_size,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-18 02:46:09 +08:00
struct rc_map_table {
V4L/DVB: ir-core: Add support for badly-implemented hardware decoders A few hardware Remote Controller decoders, even using a standard protocol, aren't able to provide the entire scancode. Due to that, the capability of using other IR's are limited on those hardware. Adds a way to indicate to ir-core what are the bits that the hardware provides, from a scancode, allowing the addition of a complete IR table to the kernel and allowing a limited support for changing the Remote Controller on those devices. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-05 01:06:55 +08:00
u32 scancode;
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
u32 keycode;
};
[media] rc: Properly name the rc_map struct The struct that describes a rc mapping had an weird and long name. We should properly name it, to make easier for developers to work with it, and to avoid confusion. Basically, generated by this script: for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode_table,rc_map,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_tab,rc_map,g <$i >a && mv a $i; done (and manually fixed where needed) Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-18 01:28:27 +08:00
struct rc_map {
[media] rc: Name RC keymap tables as rc_map_table Remote keytables had different names all over the place. Part of the fault is due to a bad naming when rc subsystem was created, but there were lots of old names that were still here. Use a common standard for everything. Patch generated by this script: for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode,rc_map_table,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_codes_,rc_map_,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_key_map,rc_map_table,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_map_table_size,rc_map_size,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-18 02:46:09 +08:00
struct rc_map_table *scan;
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
unsigned int size; /* Max number of entries */
unsigned int len; /* Used number of entries */
unsigned int alloc; /* Size of *scan in bytes */
[media] rc-core: add separate defines for protocol bitmaps and numbers 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 <david@hardeman.nu> Cc: Andy Walls <awalls@md.metrocast.net> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Antti Palosaari <crope@iki.fi> Cc: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-12 06:11:54 +08:00
enum rc_type rc_type;
Input: media/IR - switch to using new keycode interface Switch the code to use new style of getkeycode and setkeycode methods to allow retrieving and setting keycodes not only by their scancodes but also by index. Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-09-10 12:59:11 +08:00
const char *name;
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
spinlock_t lock;
};
[media] rc: use rc_map_ prefix for all rc map tables Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-18 02:56:53 +08:00
struct rc_map_list {
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
struct list_head list;
[media] rc: Properly name the rc_map struct The struct that describes a rc mapping had an weird and long name. We should properly name it, to make easier for developers to work with it, and to avoid confusion. Basically, generated by this script: for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode_table,rc_map,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_tab,rc_map,g <$i >a && mv a $i; done (and manually fixed where needed) Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-18 01:28:27 +08:00
struct rc_map map;
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
};
/* Routines from rc-map.c */
[media] rc: use rc_map_ prefix for all rc map tables Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-18 02:56:53 +08:00
int rc_map_register(struct rc_map_list *map);
void rc_map_unregister(struct rc_map_list *map);
struct rc_map *rc_map_get(const char *name);
V4L/DVB: ir-core: move rc map code to rc-map.h The keymaps don't need to be recompiled every time a change at ir-core.h happens, since it only depends on rc-map defines. By moving those definitions to the proper header, the code became cleaner, and avoids needing to recompile all the RC maps every time a non-related change is introduced. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-04 23:38:57 +08:00
void rc_map_init(void);
/* Names of the several keytables defined in-kernel */
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_ADSTECH_DVB_T_PCI "rc-adstech-dvb-t-pci"
[media] A-Link DTU(m) remote controller Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-12 05:54:13 +08:00
#define RC_MAP_ALINK_DTU_M "rc-alink-dtu-m"
[media] Anysee remote controller Anysee remote controller keytable. Uses NEC address 0x08. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-18 03:16:13 +08:00
#define RC_MAP_ANYSEE "rc-anysee"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_APAC_VIEWCOMP "rc-apac-viewcomp"
#define RC_MAP_ASUS_PC39 "rc-asus-pc39"
[media] patch for Asus My Cinema PS3-100 (1043:48cd) Signed-off-by: Remi Schwartz <remi.schwartz@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-05-19 17:11:47 +08:00
#define RC_MAP_ASUS_PS3_100 "rc-asus-ps3-100"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_ATI_TV_WONDER_HD_600 "rc-ati-tv-wonder-hd-600"
[media] ati_remote: migrate to the rc subsystem The keycode mangling algorithm is kept the same, so the new external keymap has the same values as the old static table. [mchehab@redhat.com: Fix some bad whitespacing] Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-08-07 05:18:08 +08:00
#define RC_MAP_ATI_X10 "rc-ati-x10"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_AVERMEDIA_A16D "rc-avermedia-a16d"
#define RC_MAP_AVERMEDIA_CARDBUS "rc-avermedia-cardbus"
#define RC_MAP_AVERMEDIA_DVBT "rc-avermedia-dvbt"
V4L/DVB: saa7134: add RM-K6 remote control support for Avermedia M135A This change adds support for one more remote control type for Avermedia M135A (model RM-K6), shipped with Positivo machines. Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-05-11 02:43:31 +08:00
#define RC_MAP_AVERMEDIA_M135A "rc-avermedia-m135a"
V4L/DVB: saa7134: add support for Avermedia M733A This change adds support for Avermedia M733A. The original version for linux 2.6.31 was sent to me from Avermedia, original author is unknown. I ported it to current kernels, expanded and fixed key code handling for RM-K6 remote control, and added an additional pci id also supported. [mchehab@redhat.com: make checkpatch.pl happier] Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-05-08 13:23:37 +08:00
#define RC_MAP_AVERMEDIA_M733A_RM_K6 "rc-avermedia-m733a-rm-k6"
[media] AverMedia RM-KS remote controller keytable Imported from af9015.h. Initial keytable was from Jose Alberto Reguero <jareguero@telefonica.net> and Felipe Morales Moreno <felipe.morales.moreno@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-11 21:59:48 +08:00
#define RC_MAP_AVERMEDIA_RM_KS "rc-avermedia-rm-ks"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_AVERMEDIA "rc-avermedia"
#define RC_MAP_AVERTV_303 "rc-avertv-303"
[media] TwinHan AzureWave AD-TU700(704J) remote controller Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-12 04:31:59 +08:00
#define RC_MAP_AZUREWAVE_AD_TU700 "rc-azurewave-ad-tu700"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_BEHOLD_COLUMBUS "rc-behold-columbus"
#define RC_MAP_BEHOLD "rc-behold"
#define RC_MAP_BUDGET_CI_OLD "rc-budget-ci-old"
#define RC_MAP_CINERGY_1400 "rc-cinergy-1400"
#define RC_MAP_CINERGY "rc-cinergy"
[media] rc: Add rc-delock-61959 This adds the keytable for the remote that comes with the Delock 61959. NEC protocol with address 0x866b. Signed-off-by: Jakob Haufe <sur5r@sur5r.net> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-13 22:03:36 +08:00
#define RC_MAP_DELOCK_61959 "rc-delock-61959"
V4L/DVB: dib0700: break keytable into NEC and RC-5 variants Instead of having one big keytable with 2 protocols inside, break it into two separate tables, being one for NEC and another for RC-5 variants, and properly identify what variant should be used at the boards entries. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-01 19:02:35 +08:00
#define RC_MAP_DIB0700_NEC_TABLE "rc-dib0700-nec"
#define RC_MAP_DIB0700_RC5_TABLE "rc-dib0700-rc5"
[media] DigitalNow TinyTwin remote controller Signed-off-by: Antti Palosaari <crope@iki.fi> Cc: Renura Enterprises Pty Ltd <renura@digitalnow.com.au> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-23 07:23:31 +08:00
#define RC_MAP_DIGITALNOW_TINYTWIN "rc-digitalnow-tinytwin"
[media] Digittrade DVB-T USB Stick remote controller keytable Digittrade DVB-T USB Stick remote controller. Imported from af9015.h. Initial keytable was from Alain Kalker <miki@dds.nl> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-11 19:24:00 +08:00
#define RC_MAP_DIGITTRADE "rc-digittrade"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_DM1105_NEC "rc-dm1105-nec"
#define RC_MAP_DNTV_LIVE_DVBT_PRO "rc-dntv-live-dvbt-pro"
#define RC_MAP_DNTV_LIVE_DVB_T "rc-dntv-live-dvb-t"
[media] rc: add dvbsky rc keymap macro This RC will be used by DVBSky driver, added on the next patch. Signed-off-by: Nibble Max <nibble.max@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-08-06 12:40:01 +08:00
#define RC_MAP_DVBSKY "rc-dvbsky"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_EMPTY "rc-empty"
#define RC_MAP_EM_TERRATEC "rc-em-terratec"
#define RC_MAP_ENCORE_ENLTV2 "rc-encore-enltv2"
#define RC_MAP_ENCORE_ENLTV_FM53 "rc-encore-enltv-fm53"
#define RC_MAP_ENCORE_ENLTV "rc-encore-enltv"
#define RC_MAP_EVGA_INDTUBE "rc-evga-indtube"
#define RC_MAP_EZTV "rc-eztv"
#define RC_MAP_FLYDVB "rc-flydvb"
#define RC_MAP_FLYVIDEO "rc-flyvideo"
#define RC_MAP_FUSIONHDTV_MCE "rc-fusionhdtv-mce"
#define RC_MAP_GADMEI_RM008Z "rc-gadmei-rm008z"
#define RC_MAP_GENIUS_TVGO_A11MCE "rc-genius-tvgo-a11mce"
#define RC_MAP_GOTVIEW7135 "rc-gotview7135"
[media] rc/keymaps: Rename Hauppauge table as rc-hauppauge There are two "hauppauge-new" keymaps, one with protocol unknown, and the other with the protocol marked accordingly. However, both tables are miss-named. Also, the old rc-hauppauge-new is broken, as it mixes three different controllers as if they were just one. This patch solves half of the problem by renaming the correct keycode table as just rc-hauppauge. This table contains the codes for the four different types of remote controllers found on Hauppauge cards, properly mapped with their different addresses. create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c [Jarod: fix up RC_MAP_HAUPPAUGE defines] Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Jarod Wilson <jarod@redhat.com>
2011-01-24 23:18:47 +08:00
#define RC_MAP_HAUPPAUGE_NEW "rc-hauppauge"
V4L/DVB: ir-core: add imon pad and mce keymaps This adds the keymaps for the hardware decode scancodes imon devices create for their native imon pad (and mini) remotes, and the hardware scancodes generated by the imon devices when used with an rc6 windows media center ed. remote. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-17 05:28:35 +08:00
#define RC_MAP_IMON_MCE "rc-imon-mce"
#define RC_MAP_IMON_PAD "rc-imon-pad"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_IODATA_BCTV7E "rc-iodata-bctv7e"
[media] IT913X Version 1 and Version 2 keymaps IT913X V1 V2 keymaps Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-02-02 05:29:44 +08:00
#define RC_MAP_IT913X_V1 "rc-it913x-v1"
#define RC_MAP_IT913X_V2 "rc-it913x-v2"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_KAIOMY "rc-kaiomy"
#define RC_MAP_KWORLD_315U "rc-kworld-315u"
[media] Add support for KWorld PC150-U ATSC hybrid tuner card [mchehab@redhat.com: CodingStyle fixes] Signed-off-by: Kyle Strickland <kyle@kyle.strickland.name> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-02-18 13:24:53 +08:00
#define RC_MAP_KWORLD_PC150U "rc-kworld-pc150u"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_KWORLD_PLUS_TV_ANALOG "rc-kworld-plus-tv-analog"
[media] LeadTek Y04G0051 remote controller keytable Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-12 03:08:13 +08:00
#define RC_MAP_LEADTEK_Y04G0051 "rc-leadtek-y04g0051"
V4L/DVB: IR: add empty lirc pseudo-keymap Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-07-03 12:08:52 +08:00
#define RC_MAP_LIRC "rc-lirc"
V4L/DVB: Support or LME2510(C) DM04/QQBOX USB DVB-S BOXES DM04/QQBOX DVB-S USB BOX with LME2510C+SHARP:BS2F7HZ7395 or LME2510+LGTDQT-P001F tuner. [mchehab@redhat.com: Fix merge conflicts/compilation and CodingStyle issues] Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-09-03 04:29:30 +08:00
#define RC_MAP_LME2510 "rc-lme2510"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_MANLI "rc-manli"
[media] ati_remote: add keymap for Medion X10 RF remote Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-08-07 05:18:11 +08:00
#define RC_MAP_MEDION_X10 "rc-medion-x10"
[media] ati_remote: add support for Medion X10 Digitainer remote Add support for another Medion X10 remote. This was apparently originally used with the Medion Digitainer box, but is now sold separately without any Digitainer labeling. A peculiarity of this remote is a scrollwheel in place of up/down buttons. Each direction is mapped to 8 different scancodes, each corresponding to 1..8 notches, allowing multiple notches to the same direction to be transmitted in a single scancode. The driver transforms the multi-notch scancodes to multiple events of the single-notch scancode. (0x70..0x77 = 1..8 notches down, 0x78..0x7f = 1..8 notches up) Since the scrollwheel scancodes are the same that are used for mouse on some other X10 (ati_remote) remotes, the driver will now check whether the active keymap has a keycode defined for the single-notch scancode when a mouse/scrollwheel scancode (0x70..0x7f) is received. If set, scrollwheel is assumed, otherwise mouse is assumed. This remote ships with a different receiver than the already supported Medion X10 remote, but they share the same USB ID. The only difference in the USB descriptors is that the Digitainer receiver has the Remote Wakeup bit set in bmAttributes of the Configuration Descriptor. Therefore that is used to select the default keymap. Thanks to Stephan Raue from OpenELEC (www.openelec.tv) for providing me both a Medion X10 Digitainer remote+receiver and an already supported Medion X10 remote+receiver. Thanks to Martin Beyss for providing some useful information about the remote (including the "Digitainer" name). This patch has been tested by both of them and myself. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Stephan Raue <stephan@openelec.tv> Tested-by: Martin Beyss <Martin.Beyss@rwth-aachen.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-04-02 03:41:46 +08:00
#define RC_MAP_MEDION_X10_DIGITAINER "rc-medion-x10-digitainer"
[media] ati_remote: add keymap for Medion X10 OR2x remotes Add another Medion X10 remote keymap. This is for the Medion OR2x remotes with the Windows MCE button. The receiver shipped with this remote has the same USB ID as the other Medion receivers, but the name is different and is therefore used to detect this variant. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-05-14 20:52:37 +08:00
#define RC_MAP_MEDION_X10_OR2X "rc-medion-x10-or2x"
[media] MSI DIGIVOX mini II remote controller Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-12 06:12:58 +08:00
#define RC_MAP_MSI_DIGIVOX_II "rc-msi-digivox-ii"
[media] rename rc-msi-digivox.c -> rc-msi-digivox-iii.c Rename remote controller driver I added earlier. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-12 07:19:23 +08:00
#define RC_MAP_MSI_DIGIVOX_III "rc-msi-digivox-iii"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_MSI_TVANYWHERE_PLUS "rc-msi-tvanywhere-plus"
#define RC_MAP_MSI_TVANYWHERE "rc-msi-tvanywhere"
#define RC_MAP_NEBULA "rc-nebula"
#define RC_MAP_NEC_TERRATEC_CINERGY_XS "rc-nec-terratec-cinergy-xs"
#define RC_MAP_NORWOOD "rc-norwood"
#define RC_MAP_NPGTECH "rc-npgtech"
#define RC_MAP_PCTV_SEDNA "rc-pctv-sedna"
#define RC_MAP_PINNACLE_COLOR "rc-pinnacle-color"
#define RC_MAP_PINNACLE_GREY "rc-pinnacle-grey"
#define RC_MAP_PINNACLE_PCTV_HD "rc-pinnacle-pctv-hd"
#define RC_MAP_PIXELVIEW_NEW "rc-pixelview-new"
#define RC_MAP_PIXELVIEW "rc-pixelview"
[media] Add a keymap for Pixelview 002-T remote Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-18 01:39:29 +08:00
#define RC_MAP_PIXELVIEW_002T "rc-pixelview-002t"
V4L/DVB: ir-core: Add support for badly-implemented hardware decoders A few hardware Remote Controller decoders, even using a standard protocol, aren't able to provide the entire scancode. Due to that, the capability of using other IR's are limited on those hardware. Adds a way to indicate to ir-core what are the bits that the hardware provides, from a scancode, allowing the addition of a complete IR table to the kernel and allowing a limited support for changing the Remote Controller on those devices. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-05 01:06:55 +08:00
#define RC_MAP_PIXELVIEW_MK12 "rc-pixelview-mk12"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_POWERCOLOR_REAL_ANGEL "rc-powercolor-real-angel"
#define RC_MAP_PROTEUS_2309 "rc-proteus-2309"
#define RC_MAP_PURPLETV "rc-purpletv"
#define RC_MAP_PV951 "rc-pv951"
[media] rc/keymaps: Rename Hauppauge table as rc-hauppauge There are two "hauppauge-new" keymaps, one with protocol unknown, and the other with the protocol marked accordingly. However, both tables are miss-named. Also, the old rc-hauppauge-new is broken, as it mixes three different controllers as if they were just one. This patch solves half of the problem by renaming the correct keycode table as just rc-hauppauge. This table contains the codes for the four different types of remote controllers found on Hauppauge cards, properly mapped with their different addresses. create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c [Jarod: fix up RC_MAP_HAUPPAUGE defines] Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Jarod Wilson <jarod@redhat.com>
2011-01-24 23:18:47 +08:00
#define RC_MAP_HAUPPAUGE "rc-hauppauge"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_RC5_TV "rc-rc5-tv"
V4L/DVB: IR: add RC6 keymap for Windows Media Center Ed. remotes This is the RC6 keymap for the Windows Media Center Edition remotes that come bundled with MCE/eHome Infrared Remote transceivers. Tested with 3 different variants of the remote, but its possible there are still some additional keys missing, but its simple enough to add them in later... This patch also adds an IR_TYPE_ALL convenience macro to make life easier for receivers that support all IR protocols. v2: fix an erroneous comment that referred to imon devices Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-06-02 04:30:35 +08:00
#define RC_MAP_RC6_MCE "rc-rc6-mce"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_REAL_AUDIO_220_32_KEYS "rc-real-audio-220-32-keys"
[media] rc: add rc-reddo It is very similar than rc-msi-digivox-iii but new keytable is needed as there is one existing scancode mapped to different button. Also that one has less buttons. NEC extended protocol with address 0x61d6. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-13 00:59:02 +08:00
#define RC_MAP_REDDO "rc-reddo"
[media] ati_remote: add support for SnapStream Firefly remote The protocol differs by having two toggle bits in the scancode. Since one of the bits is otherwise unused, we can safely handle the bits unconditionally. [mchehab@redhat.com: Fix some bad whitespacing] Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-08-07 05:18:12 +08:00
#define RC_MAP_SNAPSTREAM_FIREFLY "rc-snapstream-firefly"
V4L/DVB: IR/streamzap: functional in-kernel decoding This patch makes in-kernel decoding with the stock Streamzap PC Remote work out of the box. There are quite a few things going on in this patch, all related to getting this working: 1) I had to enable reporting of a long space at the end of each signal, or I had weird buffering and keybounce issues. 2) The keymap has been reworked slightly to match actual decoded values, the first edition was missing the pre-data bits present in the lirc config file for this remote. 3) There's a whole new decoder included, specifically for the not-quite-RC5 15-bit protocol variant used by the Streamzap PC Remote. The decoder, while usable with other recievers (tested with an mceusb receiver), will only be loaded by the streamzap driver, as its likely not of use in almost all other situations. This can be revisited if/when all keytable loading (and disabling of unneeded protocol decoder engines) is moved to userspace, but for now, I think this makes the most sense. Note that I did try to enable handling the streamzap RC5-ish protocol in the current RC5 decoder, but there's no particularly easy way to tell if its 14-bit RC5 or 15-bit Streamzap until we see bit 14, and even then, in testing an attempted decoder merge, only 2/3 of the keys were properly recognized as being the 15-bit variant and decoded correctly, the rest were close enough to compliant with 14-bit that they were decoded as such (but they have overlap with one another, and thus we can't just shrug and use the 14-bit decoded values). Also of note in this patch is the removal of the streamzap driver's internal delay buffer. Per discussion w/Christoph, it shouldn't be needed by lirc any longer anyway, and it doesn't seem to make any difference to the in-kernel decoder engine. That being the case, I'm yanking it all out, as it greatly simplifies the driver code. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-08 00:31:40 +08:00
#define RC_MAP_STREAMZAP "rc-streamzap"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_TBS_NEC "rc-tbs-nec"
[media] rc/keymaps: add RC keytable for TechniSat TS35 The TS35 remote is distributed with TechniSat CableStar HD2 cards (mantis chipset). The exact protocol type is unknown, making this rc map probably only usable by mantis cards. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-07 03:58:09 +08:00
#define RC_MAP_TECHNISAT_TS35 "rc-technisat-ts35"
[media] technisat-usb2: added driver for Technisat's USB2.0 DVB-S/S2 receiver This patch is adding support for Technisat's new USB2.0 DVB-S/S2 receiver device. The development was sponsored by Technisat. The Green led is toggle depending on the frontend-state. The Red LED is turned on all the time. The MAC address reading from the EEPROM along with the LRC-method to check whether its valid. Support for the IR-receiver of the Technisat USB2 box. The keys of small, black remote-control are built-in, repeated key behaviour are simulated. The i2c-mutex of the dvb-usb-structure is used as a general mutex for USB requests, as there are 3 threads racing for atomic requests consisting of multiple usb-requests. A module option is there which disables the toggling of LEDs by the driver on certain triggers. Useful when being used in a "dark" environment. [mchehab@redhat.com: Fix merge conflicts with RC renaming patches] Signed-off-by: Martin Wilks <m.wilks@technisat.com> Signed-off-by: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-01 03:24:19 +08:00
#define RC_MAP_TECHNISAT_USB2 "rc-technisat-usb2"
[media] rc/keymaps: add keytable for Terratec Cinergy C PCI This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-07 03:58:10 +08:00
#define RC_MAP_TERRATEC_CINERGY_C_PCI "rc-terratec-cinergy-c-pci"
[media] rc/keymaps: add keytable for Terratec Cinergy S2 HD This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-07 03:58:11 +08:00
#define RC_MAP_TERRATEC_CINERGY_S2_HD "rc-terratec-cinergy-s2-hd"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_TERRATEC_CINERGY_XS "rc-terratec-cinergy-xs"
[media] TerraTec remote controller keytable TerraTec slim remote, 7 rows, 4 columns. Uses NEC extended 0x02bd. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-08 08:56:48 +08:00
#define RC_MAP_TERRATEC_SLIM "rc-terratec-slim"
[media] add TerraTec remote Remote used for TerraTec Cinergy T Stick RC. Keytable from Martin Groszhauser <mgroszhauser@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Cc: Martin Groszhauser <mgroszhauser@gmail.com> Cc: TerraTux <TerraTux@terratec.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-03-20 01:11:55 +08:00
#define RC_MAP_TERRATEC_SLIM_2 "rc-terratec-slim-2"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_TEVII_NEC "rc-tevii-nec"
[media] rc: add tivo/nero liquidtv keymap Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-03-24 23:58:48 +08:00
#define RC_MAP_TIVO "rc-tivo"
[media] Total Media In Hand remote controller Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-12 07:25:44 +08:00
#define RC_MAP_TOTAL_MEDIA_IN_HAND "rc-total-media-in-hand"
[media] rc/keymaps: add RC keytable for MyGica X8507 Add RC-5 remote keytable definition for MyGica X8507. [mchehab@redhat.com: fixed whitespacing - it seems that Alfredo's emailer mangled it] Signed-off-by: Alfredo J. Delaiti <alfredodelaiti@netscape.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-11-09 03:14:50 +08:00
#define RC_MAP_TOTAL_MEDIA_IN_HAND_02 "rc-total-media-in-hand-02"
[media] TrekStor DVB-T USB Stick remote controller Imported from af9015.h. Initial keytable was from Marc Schneider <macke@macke.org> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-11 18:36:54 +08:00
#define RC_MAP_TREKSTOR "rc-trekstor"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_TT_1500 "rc-tt-1500"
[media] rc/keymaps: add keytable for Twinhan DTV CAB CI This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-07 03:58:12 +08:00
#define RC_MAP_TWINHAN_DTV_CAB_CI "rc-twinhan-dtv-cab-ci"
[media] Twinhan 1027 + IR Port support Patch add support of TwinHan 1027 DVB-S card. Refreshed version of https://patchwork.kernel.org/patch/79753/ patch. (adapted for the new IR system), still works. DVB-S support come from a patch originally authored by Manu Abraham (abraham.manu@gmail.com). IR Port support were added by Sergey. Cc: Manu Abraham <abraham.manu@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-09 21:18:32 +08:00
#define RC_MAP_TWINHAN_VP1027_DVBS "rc-twinhan1027"
[media] rc-videomate-m1f.c Rename to match remote controler name This remote was added with support for card Compro VideoMate M1F. This remote is shipped with various Compro cards, not this one only. Furthermore this remote can be bought separately under name Compro VideoMate K100. http://compro.com.tw/en/product/k100/k100.html So give it a proper name. [mchehab@redhat.com: Fix the Makefile] Signed-off-by: Samuel Rakitničan <samuel.rakitnican@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-07 04:34:53 +08:00
#define RC_MAP_VIDEOMATE_K100 "rc-videomate-k100"
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
#define RC_MAP_VIDEOMATE_S350 "rc-videomate-s350"
#define RC_MAP_VIDEOMATE_TV_PVR "rc-videomate-tv-pvr"
#define RC_MAP_WINFAST "rc-winfast"
#define RC_MAP_WINFAST_USBII_DELUXE "rc-winfast-usbii-deluxe"
[media] dw2102: Use RC Core instead of the legacy RC (second edition) Use RC Core instead of the legacy RC. DVBWorld, TBS, TeVii, Prof hardware decode only NEC remotes (one byte code). Geniatech hardware decode only RC5 (two bytes). + New keymap for Geniatech HDStar (SU3000). Signed-off-by: Evgeny Plehov <EvgenyPlehov@ukr.net> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-16 03:43:33 +08:00
#define RC_MAP_SU3000 "rc-su3000"
V4L/DVB: Add a keymap file with dib0700 table Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-01 06:24:49 +08:00
V4L/DVB: ir-core: Make use of the new IR keymap modules Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-03 07:01:00 +08:00
/*
* Please, do not just append newer Remote Controller names at the end.
* The names should be ordered in alphabetical order
*/