2010-11-17 19:28:38 +03:00
|
|
|
menuconfig RC_CORE
|
|
|
|
tristate "Remote Controller adapters"
|
2009-12-11 14:00:00 +03:00
|
|
|
depends on INPUT
|
|
|
|
default INPUT
|
2010-08-09 17:07:20 +04:00
|
|
|
---help---
|
|
|
|
Enable support for Remote Controllers on Linux. This is
|
|
|
|
needed in order to support several video capture adapters.
|
2010-11-17 19:28:38 +03:00
|
|
|
Currently, all supported devices use InfraRed.
|
2009-12-11 14:34:07 +03:00
|
|
|
|
2010-08-09 17:07:20 +04:00
|
|
|
Enable this option if you have a video capture board even
|
|
|
|
if you don't need IR, as otherwise, you may not be able to
|
|
|
|
compile the driver for your adapter.
|
2010-07-31 18:59:14 +04:00
|
|
|
|
2010-11-17 19:28:38 +03:00
|
|
|
if RC_CORE
|
2010-08-09 17:07:20 +04:00
|
|
|
|
2010-07-03 08:06:57 +04:00
|
|
|
config LIRC
|
|
|
|
tristate
|
|
|
|
default y
|
|
|
|
|
|
|
|
---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
|
2010-07-31 18:59:14 +04:00
|
|
|
LIRC daemon handles protocol decoding for IR reception and
|
2010-07-03 08:06:57 +04:00
|
|
|
encoding for IR transmitting (aka "blasting").
|
|
|
|
|
2010-11-10 05:00:14 +03:00
|
|
|
source "drivers/media/rc/keymaps/Kconfig"
|
V4L/DVB: Break Remote Controller keymaps into modules
The original Remote Controller approach were very messy: a big file,
that were part of ir-common kernel module, containing 64 different
RC keymap tables, used by the V4L/DVB drivers.
Better to break each RC keymap table into a separate module,
registering them into rc core on a process similar to the fs/nls tables.
As an userspace program is now in charge of loading those tables,
adds an option to allow the complete removal of those tables from
kernelspace.
Yet, on embedded devices like Set Top Boxes and TV sets, maybe the
only available input device is the IR. So, we should keep allowing
the usage of in-kernel tables, but a latter patch should change
the default to 'n', after giving some time for distros to add
the v4l-utils with the ir-keytable program, to allow the table
load via userspace.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-04-02 10:05:46 +04:00
|
|
|
|
2010-03-25 02:47:53 +03:00
|
|
|
config IR_NEC_DECODER
|
2010-04-09 16:20:11 +04:00
|
|
|
tristate "Enable IR raw decoder for the NEC protocol"
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-05-14 21:09:57 +04:00
|
|
|
select BITREVERSE
|
2010-03-25 02:47:53 +03:00
|
|
|
default y
|
|
|
|
|
|
|
|
---help---
|
|
|
|
Enable this option if you have IR with NEC protocol, and
|
|
|
|
if the IR is decoded in software
|
2010-04-04 17:27:20 +04:00
|
|
|
|
|
|
|
config IR_RC5_DECODER
|
2010-04-09 16:20:11 +04:00
|
|
|
tristate "Enable IR raw decoder for the RC-5 protocol"
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-05-26 21:08:51 +04:00
|
|
|
select BITREVERSE
|
2010-04-04 17:27:20 +04:00
|
|
|
default y
|
|
|
|
|
|
|
|
---help---
|
|
|
|
Enable this option if you have IR with RC-5 protocol, and
|
|
|
|
if the IR is decoded in software
|
2010-04-09 03:04:40 +04:00
|
|
|
|
|
|
|
config IR_RC6_DECODER
|
|
|
|
tristate "Enable IR raw decoder for the RC6 protocol"
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-05-26 21:08:51 +04:00
|
|
|
select BITREVERSE
|
2010-04-09 03:04:40 +04:00
|
|
|
default y
|
|
|
|
|
|
|
|
---help---
|
|
|
|
Enable this option if you have an infrared remote control which
|
|
|
|
uses the RC6 protocol, and you need software decoding support.
|
2010-04-17 01:29:02 +04:00
|
|
|
|
2010-04-16 01:46:05 +04:00
|
|
|
config IR_JVC_DECODER
|
|
|
|
tristate "Enable IR raw decoder for the JVC protocol"
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-07-08 03:41:15 +04:00
|
|
|
select BITREVERSE
|
2010-04-16 01:46:05 +04:00
|
|
|
default y
|
|
|
|
|
|
|
|
---help---
|
|
|
|
Enable this option if you have an infrared remote control which
|
|
|
|
uses the JVC protocol, and you need software decoding support.
|
|
|
|
|
2010-04-16 01:46:10 +04:00
|
|
|
config IR_SONY_DECODER
|
|
|
|
tristate "Enable IR raw decoder for the Sony protocol"
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-04-16 01:46:10 +04:00
|
|
|
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-07 20:31:40 +04:00
|
|
|
config IR_RC5_SZ_DECODER
|
|
|
|
tristate "Enable IR raw decoder for the RC-5 (streamzap) protocol"
|
2010-11-17 19:28:38 +03:00
|
|
|
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-07 20:31:40 +04: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).
|
|
|
|
|
2010-07-03 08:07:53 +04:00
|
|
|
config IR_LIRC_CODEC
|
|
|
|
tristate "Enable IR to LIRC bridge"
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-07-03 08:07:53 +04:00
|
|
|
depends on LIRC
|
|
|
|
default y
|
|
|
|
|
|
|
|
---help---
|
|
|
|
Enable this option to pass raw IR to and from userspace via
|
|
|
|
the LIRC interface.
|
|
|
|
|
2010-10-08 23:23:56 +04:00
|
|
|
config IR_ENE
|
2010-09-07 01:26:11 +04:00
|
|
|
tristate "ENE eHome Receiver/Transceiver (pnp id: ENE0100/ENE02xxx)"
|
2010-10-08 23:23:56 +04:00
|
|
|
depends on PNP
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-10-08 23:23:56 +04:00
|
|
|
---help---
|
|
|
|
Say Y here to enable support for integrated infrared receiver
|
2010-09-07 01:26:11 +04:00
|
|
|
/transceiver made by ENE.
|
2010-10-08 23:23:56 +04:00
|
|
|
|
|
|
|
You can see if you have it by looking at lspnp output.
|
2010-09-07 01:26:11 +04:00
|
|
|
Output should include ENE0100 ENE0200 or something similar.
|
2010-10-08 23:23:56 +04:00
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
module will be called ene_ir.
|
|
|
|
|
2010-04-17 01:29:02 +04:00
|
|
|
config IR_IMON
|
|
|
|
tristate "SoundGraph iMON Receiver and Display"
|
|
|
|
depends on USB_ARCH_HAS_HCD
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-04-17 01:29:02 +04:00
|
|
|
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.
|
2010-06-02 00:32:08 +04:00
|
|
|
|
|
|
|
config IR_MCEUSB
|
|
|
|
tristate "Windows Media Center Ed. eHome Infrared Transceiver"
|
|
|
|
depends on USB_ARCH_HAS_HCD
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-06-02 00:32:08 +04:00
|
|
|
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.
|
2010-08-02 22:46:03 +04:00
|
|
|
|
2011-03-16 23:14:52 +03:00
|
|
|
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-25 20:35:13 +04: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.
|
|
|
|
|
2010-10-08 23:23:56 +04:00
|
|
|
config IR_NUVOTON
|
|
|
|
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
|
2010-07-31 18:59:26 +04:00
|
|
|
depends on PNP
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-07-31 18:59:26 +04:00
|
|
|
---help---
|
|
|
|
Say Y here to enable support for integrated infrared receiver
|
2010-10-08 23:23:56 +04:00
|
|
|
/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).
|
2010-07-31 18:59:26 +04:00
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
2010-10-08 23:23:56 +04:00
|
|
|
module will be called nuvoton-cir.
|
2010-07-31 18:59:26 +04:00
|
|
|
|
[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-04 21:02:42 +04: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.
|
|
|
|
|
2010-08-02 22:46:03 +04:00
|
|
|
config IR_STREAMZAP
|
|
|
|
tristate "Streamzap PC Remote IR Receiver"
|
|
|
|
depends on USB_ARCH_HAS_HCD
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2010-08-02 22:46:03 +04:00
|
|
|
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.
|
2010-07-31 18:59:14 +04:00
|
|
|
|
2010-10-29 23:08:28 +04:00
|
|
|
config IR_WINBOND_CIR
|
2011-03-22 21:03:09 +03:00
|
|
|
tristate "Winbond IR remote control"
|
|
|
|
depends on X86 && PNP
|
2010-11-17 19:28:38 +03:00
|
|
|
depends on RC_CORE
|
2011-03-22 21:03:09 +03:00
|
|
|
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
|
2010-10-29 23:08:28 +04:00
|
|
|
motherboards).
|
|
|
|
|
2011-03-22 21:03:09 +03:00
|
|
|
To compile this driver as a module, choose M here: the module will
|
2010-10-29 23:08:28 +04:00
|
|
|
be called winbond_cir.
|
|
|
|
|
2010-11-26 00:36:27 +03:00
|
|
|
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.
|
|
|
|
|
2010-11-17 19:28:38 +03:00
|
|
|
endif #RC_CORE
|