linux/drivers/media/rc/Makefile

36 lines
1.3 KiB
Makefile
Raw Normal View History

rc-core-objs := rc-main.o ir-raw.o
obj-y += keymaps/
obj-$(CONFIG_RC_CORE) += rc-core.o
obj-$(CONFIG_LIRC) += lirc_dev.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
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
obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o
obj-$(CONFIG_IR_SANYO_DECODER) += ir-sanyo-decoder.o
obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
[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
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
[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
obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
[media] IR: add driver for Nuvoton w836x7hg integrated CIR This is a new ir-core pnp driver for the Nuvoton w836x7hg integrated CIR function. The chip is found on at least the ASRock ION 330HT boxes and apparently, on a number of Intel DP55-series motherboards: http://www.asrock.com/nettop/overview.asp?Model=ION%20330HT http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17685&lang=eng This driver was made possible by a hardware donation from Nuvoton, along with sample code (in the form of an lirc driver) and datasheet, so huge thanks to them for supporting this effort. Note that this driver constitutes a massive rewrite, porting from the lirc interfaces to the ir-core interfaces, and restructuring the driver to look more like Maxim Levitsky's ene_ir driver (as well as generally making it look more like kernel code). There's some work left to be done on this driver, to fully support the range of functionality possible, but receive and IR power-on/wake are both functional (may require setting wake key under another OS atm). The hardware I've got (one of the ASRock boxes) only supports RX, so TX is completely untested as of yet. Certain RX parameters, like sample resolution and RX IRQ sample length trigger level could possibly stand to be made tweakable via modparams or sysfs nodes, but the current values work well enough for me w/an MCE RC6A remote. The original lirc driver carried support for the Windows MCE IR keyboard/mouse device, which I plan to add back generically, in a way that should be usable by any raw IR receiver (or at least by this driver and the mceusb driver). Suspend and resume have also been tested, the power button on my remote can be used to wake the machine, and CIR functionality resumes just fine. Module unload/reload has also been tested, though not extensively or repetitively. Also tested to work with the lirc bridge plugin for userspace decoding. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-08 04:50:34 +08:00
obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
[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
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
obj-$(CONFIG_IR_RX51) += ir-rx51.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_IMG) += img-ir/