OpenCloudOS-Kernel/drivers/media/rc/Kconfig

284 lines
8.0 KiB
Plaintext
Raw Normal View History

config RC_CORE
tristate
depends on MEDIA_RC_SUPPORT
depends on INPUT
default y
V4L/DVB: Fix IR_CORE dependencies As pointed by Randy Dunlap <randy.dunlap@oracle.com>: > ERROR: "ir_keydown" [drivers/media/video/ir-kbd-i2c.ko] undefined! > ERROR: "__ir_input_register" [drivers/media/video/ir-kbd-i2c.ko] undefined! > ERROR: "get_rc_map" [drivers/media/video/ir-kbd-i2c.ko] undefined! > ERROR: "ir_input_unregister" [drivers/media/video/ir-kbd-i2c.ko] undefined! > ERROR: "get_rc_map" [drivers/media/video/cx88/cx88xx.ko] undefined! > ERROR: "ir_repeat" [drivers/media/video/cx88/cx88xx.ko] undefined! > ERROR: "ir_input_unregister" [drivers/media/video/cx88/cx88xx.ko] undefined! > ERROR: "ir_keydown" [drivers/media/video/cx88/cx88xx.ko] undefined! > ERROR: "__ir_input_register" [drivers/media/video/cx88/cx88xx.ko] undefined! > ERROR: "get_rc_map" [drivers/media/video/bt8xx/bttv.ko] undefined! > ERROR: "ir_input_unregister" [drivers/media/video/bt8xx/bttv.ko] undefined! > ERROR: "__ir_input_register" [drivers/media/video/bt8xx/bttv.ko] undefined! > ERROR: "ir_g_keycode_from_table" [drivers/media/IR/ir-common.ko] undefined! > > > #5101: > (.text+0x8306e2): undefined reference to `ir_core_debug' > (.text+0x830729): undefined reference to `ir_core_debug' > ir-functions.c:(.text+0x830906): undefined reference to `ir_core_debug' > (.text+0x8309d8): undefined reference to `ir_g_keycode_from_table' > (.text+0x830acf): undefined reference to `ir_core_debug' > (.text+0x830b92): undefined reference to `ir_core_debug' > (.text+0x830bef): undefined reference to `ir_core_debug' > (.text+0x830c6a): undefined reference to `ir_core_debug' > (.text+0x830cf7): undefined reference to `ir_core_debug' > budget-ci.c:(.text+0x89f5c8): undefined reference to `ir_keydown' > budget-ci.c:(.text+0x8a0c58): undefined reference to `get_rc_map' > budget-ci.c:(.text+0x8a0c80): undefined reference to `__ir_input_register' > budget-ci.c:(.text+0x8a0ee0): undefined reference to `get_rc_map' > budget-ci.c:(.text+0x8a11cd): undefined reference to `ir_input_unregister' > (.text+0x8a8adb): undefined reference to `ir_input_unregister' > dvb-usb-remote.c:(.text+0x8a9188): undefined reference to `get_rc_map' > dvb-usb-remote.c:(.text+0x8a91b1): undefined reference to `__ir_input_register' > dvb-usb-remote.c:(.text+0x8a9238): undefined reference to `get_rc_map' > dib0700_core.c:(.text+0x8b04ca): undefined reference to `ir_keydown' > dib0700_devices.c:(.text+0x8b2ea8): undefined reference to `ir_keydown' > dib0700_devices.c:(.text+0x8b2ef0): undefined reference to `ir_keydown' Those breakages seem to be caused by two bad things at IR_CORE Kconfig: 1) cx23885 is using select for IR_CORE; 2) the dvb-usb and sms dependency for IR_CORE were missing. While here, allow users to un-select IR. Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-09 21:07:20 +08:00
source "drivers/media/rc/keymaps/Kconfig"
menuconfig RC_DECODERS
bool "Remote controller decoders"
depends on RC_CORE
default y
if RC_DECODERS
config LIRC
tristate "LIRC interface driver"
depends on RC_CORE
---help---
Enable this option to build the Linux Infrared Remote
Control (LIRC) core device interface driver. The LIRC
interface passes raw IR to and from userspace, where the
LIRC daemon handles protocol decoding for IR reception and
encoding for IR transmitting (aka "blasting").
config IR_NEC_DECODER
tristate "Enable IR raw decoder for the NEC protocol"
depends on RC_CORE
select BITREVERSE
default y
---help---
Enable this option if you have IR with NEC protocol, and
if the IR is decoded in software
config IR_RC5_DECODER
tristate "Enable IR raw decoder for the RC-5 protocol"
depends on RC_CORE
select BITREVERSE
default y
---help---
Enable this option if you have IR with RC-5 protocol, and
if the IR is decoded in software
config IR_RC6_DECODER
tristate "Enable IR raw decoder for the RC6 protocol"
depends on RC_CORE
select BITREVERSE
default y
---help---
Enable this option if you have an infrared remote control which
uses the RC6 protocol, and you need software decoding support.
config IR_JVC_DECODER
tristate "Enable IR raw decoder for the JVC protocol"
depends on RC_CORE
select BITREVERSE
default y
---help---
Enable this option if you have an infrared remote control which
uses the JVC protocol, and you need software decoding support.
config IR_SONY_DECODER
tristate "Enable IR raw decoder for the Sony protocol"
depends on RC_CORE
select BITREVERSE
default y
---help---
Enable this option if you have an infrared remote control which
uses the Sony protocol, and you need software decoding support.
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
config IR_RC5_SZ_DECODER
tristate "Enable IR raw decoder for the RC-5 (streamzap) protocol"
depends on RC_CORE
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
select BITREVERSE
default y
---help---
Enable this option if you have IR with RC-5 (streamzap) protocol,
and if the IR is decoded in software. (The Streamzap PC Remote
uses an IR protocol that is almost standard RC-5, but not quite,
as it uses an additional bit).
config IR_SANYO_DECODER
tristate "Enable IR raw decoder for the Sanyo protocol"
depends on RC_CORE
default y
---help---
Enable this option if you have an infrared remote control which
uses the Sanyo protocol (Sanyo, Aiwa, Chinon remotes),
and you need software decoding support.
[media] rc-core support for Microsoft IR keyboard/mouse This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and transceiver requirements and specifications document, which also touches on this IR keyboard/mouse device. Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver. Successfully tested with multiple mceusb-driven transceivers, as well as with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware with enough sampling resolution should be able to use this decoder, nothing about it is at all receiver-hardware-specific. This work is inspired by lirc_mod_mce: The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table, a few defines, and some of the keyboard and mouse data parsing bits from lirc_mod_mce though. Special thanks to James Meyer for providing the hardware, and being patient with me as I took forever to get around to writing this. callback routine to ensure we don't get any stuck keys, and used symbolic names for the keytable. Also cc'ing Florian this time, who I believe is the original mod-mce author... CC: Florian Demski <fdemski@users.sourceforge.net> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-14 05:09:48 +08:00
config IR_MCE_KBD_DECODER
tristate "Enable IR raw decoder for the MCE keyboard/mouse protocol"
depends on RC_CORE
select BITREVERSE
default y
---help---
Enable this option if you have a Microsoft Remote Keyboard for
Windows Media Center Edition, which you would like to use with
a raw IR receiver in your system.
endif #RC_DECODERS
[media] rc-core support for Microsoft IR keyboard/mouse This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and transceiver requirements and specifications document, which also touches on this IR keyboard/mouse device. Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver. Successfully tested with multiple mceusb-driven transceivers, as well as with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware with enough sampling resolution should be able to use this decoder, nothing about it is at all receiver-hardware-specific. This work is inspired by lirc_mod_mce: The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table, a few defines, and some of the keyboard and mouse data parsing bits from lirc_mod_mce though. Special thanks to James Meyer for providing the hardware, and being patient with me as I took forever to get around to writing this. callback routine to ensure we don't get any stuck keys, and used symbolic names for the keytable. Also cc'ing Florian this time, who I believe is the original mod-mce author... CC: Florian Demski <fdemski@users.sourceforge.net> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-14 05:09:48 +08:00
menuconfig RC_DEVICES
bool "Remote Controller devices"
depends on RC_CORE
if RC_DEVICES
config IR_LIRC_CODEC
tristate "Enable IR to LIRC bridge"
depends on RC_CORE
depends on LIRC
default y
---help---
Enable this option to pass raw IR to and from userspace via
the LIRC interface.
config RC_ATI_REMOTE
tristate "ATI / X10 based USB RF remote controls"
depends on USB_ARCH_HAS_HCD
depends on RC_CORE
select USB
help
Say Y here if you want to use an X10 based USB remote control.
These are RF remotes with USB receivers.
Such devices include the ATI remote that comes with many of ATI's
All-In-Wonder video cards, the X10 "Lola" remote, NVIDIA RF remote,
Medion RF remote, and SnapStream FireFly remote.
This driver provides mouse pointer, left and right mouse buttons,
and maps all the other remote buttons to keypress events.
To compile this driver as a module, choose M here: the module will be
called ati_remote.
config IR_ENE
tristate "ENE eHome Receiver/Transceiver (pnp id: ENE0100/ENE02xxx)"
depends on PNP
depends on RC_CORE
---help---
Say Y here to enable support for integrated infrared receiver
/transceiver made by ENE.
You can see if you have it by looking at lspnp output.
Output should include ENE0100 ENE0200 or something similar.
To compile this driver as a module, choose M here: the
module will be called ene_ir.
config IR_IMON
tristate "SoundGraph iMON Receiver and Display"
depends on USB_ARCH_HAS_HCD
depends on RC_CORE
select USB
---help---
Say Y here if you want to use a SoundGraph iMON (aka Antec Veris)
IR Receiver and/or LCD/VFD/VGA display.
To compile this driver as a module, choose M here: the
module will be called imon.
config IR_MCEUSB
tristate "Windows Media Center Ed. eHome Infrared Transceiver"
depends on USB_ARCH_HAS_HCD
depends on RC_CORE
select USB
---help---
Say Y here if you want to use a Windows Media Center Edition
eHome Infrared Transceiver.
To compile this driver as a module, choose M here: the
module will be called mceusb.
config IR_ITE_CIR
tristate "ITE Tech Inc. IT8712/IT8512 Consumer Infrared Transceiver"
depends on PNP
depends on RC_CORE
---help---
Say Y here to enable support for integrated infrared receivers
/transceivers made by ITE Tech Inc. These are found in
several ASUS devices, like the ASUS Digimatrix or the ASUS
EEEBox 1501U.
To compile this driver as a module, choose M here: the
module will be called ite-cir.
[media] fintek-cir: new driver for Fintek LPC SuperIO CIR function This is a new driver for the Fintek LPC SuperIO CIR function, in the Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so thanks go to them for supporting this effort. This driver started out as a copy of the nuvoton-cir driver, and was then modified as needed for the Fintek chip. The two share many similaries, though the buffer handling for the Fintek chip is actually nearly identical to the mceusb buffer handling, so the parser routine is almost a drop-in copy of the mceusb buffer parser (a candidate for being abstracted out into shared code at some point). This initial code drop *only* supports receive, but the hardware does support transmit as well. I really haven't even started to look at what's required, but my guess is that its also pretty similar to mceusb. Most people are probably only really interested in RX anyway though, so I think its good to get this out there even with only RX. (Nb: there are also Fintek-made mceusb receivers, which presumably, this chip shares CIR hardware with). This hardware can be found on at least Jetway NC98 boards and derivative systems, and likely others as well. Functionality was tested with an NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge) and NEC-ish (tivo) remotes all successful, as was lirc userspace decode of the RC6 remote. CC: Aaron Huang <aaron_huang@fintek.com.tw> CC: Tom Tsai <tom_tsai@fintek.com.tw> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-26 00:35:13 +08:00
config IR_FINTEK
tristate "Fintek Consumer Infrared Transceiver"
depends on PNP
depends on RC_CORE
---help---
Say Y here to enable support for integrated infrared receiver
/transciever made by Fintek. This chip is found on assorted
Jetway motherboards (and of course, possibly others).
To compile this driver as a module, choose M here: the
module will be called fintek-cir.
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
depends on RC_CORE
---help---
Say Y here to enable support for integrated infrared receiver
/transciever made by Nuvoton (formerly Winbond). This chip is
found in the ASRock ION 330HT, as well as assorted Intel
DP55-series motherboards (and of course, possibly others).
To compile this driver as a module, choose M here: the
module will be called nuvoton-cir.
[media] redrat3: new rc-core IR transceiver device driver This is a new rc-core device driver for the IR transceivers made by RedRat Ltd. (http://redrat.co.uk/). It started out life as an out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge, by Stephen Cox. He started porting it to what was then ir-core, and I finally picked it up about two week ago and did a fairly large overhaul on it, and its now into a state where I'm fairly comfortable submitting it here for review and inclusion in the kernel. I'm claiming authorship of this driver, since while it started out as Stephen's work, its definitely a derivative work now, at 876 lines added and 1698 lines removed since grabbing it from sourceforge. Stephen's name is retained as secondary author though, and credited in the headers. Those interested in seeing how the changes evolved can (at least for now) look at this branch in my git tree: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3 That won't be around forever though, and I'm doing this as a single commit to go into mainline. Anyway... I've successfully tested in-kernel decode of rc5, rc6 and nec remotes, as well as lirc userspace decode of rc5 and rc6. There are still some quirks here to sort out with rc5 lirc userspace decode, but I'm working with the RedRat folks themselves to figure out what's going on there (rc5 lirc decode works, but you only get an event on key release -- in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of rc6 is working perfectly. Transmit is also working, tested by pointing the redrat3 at an mceusb transceiver, which happily picked up the transmitted signals and properly decoded them. There's no default remote for this hardware, so its somewhat arbitrarily set to use the Hauppauge RC5 keymap by default. Easily changed out by way of ir-keytable and irrelevant if you're using lircd for decode. CC: Chris Dodge <chris@redrat.co.uk> CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk> CC: Stephen Cox <scox_nz@yahoo.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-05 01:02:42 +08:00
config IR_REDRAT3
tristate "RedRat3 IR Transceiver"
depends on USB_ARCH_HAS_HCD
depends on RC_CORE
select USB
---help---
Say Y here if you want to use a RedRat3 Infrared Transceiver.
To compile this driver as a module, choose M here: the
module will be called redrat3.
config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
depends on RC_CORE
select USB
---help---
Say Y here if you want to use a Streamzap PC Remote
Infrared Receiver.
To compile this driver as a module, choose M here: the
module will be called streamzap.
config IR_WINBOND_CIR
tristate "Winbond IR remote control"
depends on X86 && PNP
depends on RC_CORE
select NEW_LEDS
select LEDS_CLASS
select LEDS_TRIGGERS
select BITREVERSE
---help---
Say Y here if you want to use the IR remote functionality found
in some Winbond SuperI/O chips. Currently only the WPCD376I
chip is supported (included in some Intel Media series
motherboards).
To compile this driver as a module, choose M here: the module will
be called winbond_cir.
config RC_LOOPBACK
tristate "Remote Control Loopback Driver"
depends on RC_CORE
---help---
Say Y here if you want support for the remote control loopback
driver which allows TX data to be sent back as RX data.
This is mostly useful for debugging purposes.
If you're not sure, select N here.
To compile this driver as a module, choose M here: the module will
be called rc_loopback.
config IR_GPIO_CIR
tristate "GPIO IR remote control"
depends on RC_CORE
---help---
Say Y if you want to use GPIO based IR Receiver.
To compile this driver as a module, choose M here: the module will
be called gpio-ir-recv.
endif #RC_DEVICES