linux_dsm_epyc7002/include/media/rc-map.h

219 lines
10 KiB
C
Raw Normal View History

/*
* rc-map.h - define RC map names used by RC drivers
*
* Copyright (c) 2010 by Mauro Carvalho Chehab
*
* 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.
*/
#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 05:11:54 +07:00
enum rc_type {
RC_TYPE_UNKNOWN = 0, /* Protocol not known */
RC_TYPE_OTHER = 1, /* Protocol known but proprietary */
RC_TYPE_LIRC = 2, /* Pass raw IR to lirc userspace */
RC_TYPE_RC5 = 3, /* Philips RC5 protocol */
RC_TYPE_RC5X = 4, /* Philips RC5x protocol */
RC_TYPE_RC5_SZ = 5, /* StreamZap variant of RC5 */
RC_TYPE_JVC = 6, /* JVC protocol */
RC_TYPE_SONY12 = 7, /* Sony 12 bit protocol */
RC_TYPE_SONY15 = 8, /* Sony 15 bit protocol */
RC_TYPE_SONY20 = 9, /* Sony 20 bit protocol */
RC_TYPE_NEC = 10, /* NEC protocol */
RC_TYPE_SANYO = 11, /* Sanyo protocol */
RC_TYPE_MCE_KBD = 12, /* RC6-ish MCE keyboard/mouse */
RC_TYPE_RC6_0 = 13, /* Philips RC6-0-16 protocol */
RC_TYPE_RC6_6A_20 = 14, /* Philips RC6-6A-20 protocol */
RC_TYPE_RC6_6A_24 = 15, /* Philips RC6-6A-24 protocol */
RC_TYPE_RC6_6A_32 = 16, /* Philips RC6-6A-32 protocol */
RC_TYPE_RC6_MCE = 17, /* MCE (Philips RC6-6A-32 subtype) protocol */
RC_TYPE_SHARP = 18, /* Sharp protocol */
RC_TYPE_XMP = 19, /* 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 05:11:54 +07: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_LIRC (1 << RC_TYPE_LIRC)
#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)
#define RC_BIT_SHARP (1 << RC_TYPE_SHARP)
#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 05:11:54 +07:00
#define RC_BIT_ALL (RC_BIT_UNKNOWN | RC_BIT_OTHER | RC_BIT_LIRC | \
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 | \
RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE | RC_BIT_SHARP | \
RC_BIT_XMP)
#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))
struct rc_map_table {
u32 scancode;
u32 keycode;
};
struct rc_map {
struct rc_map_table *scan;
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 05:11:54 +07:00
enum rc_type rc_type;
const char *name;
spinlock_t lock;
};
struct rc_map_list {
struct list_head list;
struct rc_map map;
};
/* Routines from rc-map.c */
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);
void rc_map_init(void);
/* Names of the several keytables defined in-kernel */
#define RC_MAP_ADSTECH_DVB_T_PCI "rc-adstech-dvb-t-pci"
#define RC_MAP_ALINK_DTU_M "rc-alink-dtu-m"
#define RC_MAP_ANYSEE "rc-anysee"
#define RC_MAP_APAC_VIEWCOMP "rc-apac-viewcomp"
#define RC_MAP_ASUS_PC39 "rc-asus-pc39"
#define RC_MAP_ASUS_PS3_100 "rc-asus-ps3-100"
#define RC_MAP_ATI_TV_WONDER_HD_600 "rc-ati-tv-wonder-hd-600"
#define RC_MAP_ATI_X10 "rc-ati-x10"
#define RC_MAP_AVERMEDIA_A16D "rc-avermedia-a16d"
#define RC_MAP_AVERMEDIA_CARDBUS "rc-avermedia-cardbus"
#define RC_MAP_AVERMEDIA_DVBT "rc-avermedia-dvbt"
#define RC_MAP_AVERMEDIA_M135A "rc-avermedia-m135a"
#define RC_MAP_AVERMEDIA_M733A_RM_K6 "rc-avermedia-m733a-rm-k6"
#define RC_MAP_AVERMEDIA_RM_KS "rc-avermedia-rm-ks"
#define RC_MAP_AVERMEDIA "rc-avermedia"
#define RC_MAP_AVERTV_303 "rc-avertv-303"
#define RC_MAP_AZUREWAVE_AD_TU700 "rc-azurewave-ad-tu700"
#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"
#define RC_MAP_DELOCK_61959 "rc-delock-61959"
#define RC_MAP_DIB0700_NEC_TABLE "rc-dib0700-nec"
#define RC_MAP_DIB0700_RC5_TABLE "rc-dib0700-rc5"
#define RC_MAP_DIGITALNOW_TINYTWIN "rc-digitalnow-tinytwin"
#define RC_MAP_DIGITTRADE "rc-digittrade"
#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"
#define RC_MAP_DVBSKY "rc-dvbsky"
#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"
#define RC_MAP_HAUPPAUGE_NEW "rc-hauppauge"
#define RC_MAP_IMON_MCE "rc-imon-mce"
#define RC_MAP_IMON_PAD "rc-imon-pad"
#define RC_MAP_IODATA_BCTV7E "rc-iodata-bctv7e"
#define RC_MAP_IT913X_V1 "rc-it913x-v1"
#define RC_MAP_IT913X_V2 "rc-it913x-v2"
#define RC_MAP_KAIOMY "rc-kaiomy"
#define RC_MAP_KWORLD_315U "rc-kworld-315u"
#define RC_MAP_KWORLD_PC150U "rc-kworld-pc150u"
#define RC_MAP_KWORLD_PLUS_TV_ANALOG "rc-kworld-plus-tv-analog"
#define RC_MAP_LEADTEK_Y04G0051 "rc-leadtek-y04g0051"
#define RC_MAP_LIRC "rc-lirc"
#define RC_MAP_LME2510 "rc-lme2510"
#define RC_MAP_MANLI "rc-manli"
#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 02:41:46 +07:00
#define RC_MAP_MEDION_X10_DIGITAINER "rc-medion-x10-digitainer"
#define RC_MAP_MEDION_X10_OR2X "rc-medion-x10-or2x"
#define RC_MAP_MSI_DIGIVOX_II "rc-msi-digivox-ii"
#define RC_MAP_MSI_DIGIVOX_III "rc-msi-digivox-iii"
#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"
#define RC_MAP_PIXELVIEW_002T "rc-pixelview-002t"
#define RC_MAP_PIXELVIEW_MK12 "rc-pixelview-mk12"
#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"
#define RC_MAP_HAUPPAUGE "rc-hauppauge"
#define RC_MAP_RC5_TV "rc-rc5-tv"
#define RC_MAP_RC6_MCE "rc-rc6-mce"
#define RC_MAP_REAL_AUDIO_220_32_KEYS "rc-real-audio-220-32-keys"
#define RC_MAP_REDDO "rc-reddo"
#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-07 23:31:40 +07:00
#define RC_MAP_STREAMZAP "rc-streamzap"
#define RC_MAP_TBS_NEC "rc-tbs-nec"
#define RC_MAP_TECHNISAT_USB2 "rc-technisat-usb2"
#define RC_MAP_TERRATEC_CINERGY_XS "rc-terratec-cinergy-xs"
#define RC_MAP_TERRATEC_SLIM "rc-terratec-slim"
#define RC_MAP_TERRATEC_SLIM_2 "rc-terratec-slim-2"
#define RC_MAP_TEVII_NEC "rc-tevii-nec"
#define RC_MAP_TIVO "rc-tivo"
#define RC_MAP_TOTAL_MEDIA_IN_HAND "rc-total-media-in-hand"
#define RC_MAP_TOTAL_MEDIA_IN_HAND_02 "rc-total-media-in-hand-02"
#define RC_MAP_TREKSTOR "rc-trekstor"
#define RC_MAP_TT_1500 "rc-tt-1500"
#define RC_MAP_TWINHAN_VP1027_DVBS "rc-twinhan1027"
#define RC_MAP_VIDEOMATE_K100 "rc-videomate-k100"
#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"
#define RC_MAP_SU3000 "rc-su3000"
/*
* Please, do not just append newer Remote Controller names at the end.
* The names should be ordered in alphabetical order
*/