summaryrefslogtreecommitdiffstats
path: root/drivers/media/IR/keymaps
AgeCommit message (Collapse)AuthorFilesLines
2010-09-27V4L/DVB: IR: extend MCE keymapMaxim Levitsky1-0/+3
These keys are found on remote bundled with Toshiba Qosmio F50-10q. Found and tested by, Sami R <maesesami@gmail.com> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-08V4L/DVB: IR keymap: Add print button for HP OEM version of MCE remoteAndy Walls1-0/+2
This patch adds a defintion for the "Print" button found on HP OEM versions of the MCE remote. All of the other keys found on the HP OEM version of the remote match the other keys as already defined. Because, who doesn't need "remote printing", while one is sitting on the couch across from one's PC? ;) Signed-off-by: Andy Walls <awalls@md.metrocast.net> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-08V4L/DVB: IR: Allow not to compile keymaps inMaxim Levitsky2-45/+0
Currently, ir device registration fails if keymap requested by driver is not found. Fix that by always compiling in the empty keymap, and using it as a failback. Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-08V4L/DVB: staging/lirc: port lirc_streamzap to ir-coreJarod Wilson2-0/+82
This ports lirc_streamzap.c over to ir-core in-place, to be followed by a patch moving the driver over to drivers/media/IR/streamzap.c and enabling the proper Kconfig bits. Presently, the in-kernel keymap doesn't work, as the stock Streamzap remote uses an RC-5-like, but not-quite-RC-5 protocol, which the in-kernel RC-5 decoder doesn't cope with. The remote can be used right now with the lirc bridge driver though, and other remotes (at least an RC-6(A) MCE remote) work perfectly with the driver. I'll take a look at making the existing RC-5 decoder cope with this odd duck, possibly implement another standalone decoder engine, or just throw up my hands and say "meh, use lirc"... But the driver itself should be perfectly sound. Remaining items on the streamzap TODO list: - add LIRC_SET_REC_TIMEOUT-alike support - add LIRC_GET_M{AX,IN}_TIMEOUT-alike support - add LIRC_GET_REC_RESOLUTION-alike support All of the above should be trivial to add. There are patches pending to add this support to ir-core from Maxim Levitsky, and I'll take care of these once his patches get integrated. None of them are currently essential though. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-02V4L/DVB: standardize names at rc-dib0700 tablesMauro Carvalho Chehab2-12/+12
Use a more standard way to name those tables, as they're currently used by the script that coverts those tables to be loaded via userspace. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-02V4L/DVB: dib0700: break keytable into NEC and RC-5 variantsMauro Carvalho Chehab3-83/+129
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-02V4L/DVB: Add a keymap file with dib0700 tableMauro Carvalho Chehab2-0/+315
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-02V4L/DVB: IR: add empty lirc pseudo-keymapJarod Wilson2-0/+42
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-02V4L/DVB: IR: add RC6 keymap for Windows Media Center Ed. remotesJarod Wilson2-0/+106
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-01V4L/DVB: saa7134: add RM-K6 remote control support for Avermedia M135AHerton Ronaldo Krzesinski3-91/+148
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-06-01V4L/DVB: saa7134: add support for Avermedia M733AHerton Ronaldo Krzesinski2-0/+96
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-19V4L/DVB: IR/imon: convert to ir-core protocol change handlingJarod Wilson2-3/+4
Drop the imon driver's internal protocol definitions in favor of using those provided by ir-core. Should make ir-keytable Just Work for switching protocol on the fly on the imon devices that support both the native imon remotes and mce remotes. The imon-no-pad-stabilize pseudo-protocol was dropped as a protocol, and converted to a separate modprobe option (which it probably should have been in the first place). On the TODO list is to convert this to an as yet unwritten protocol-specific options framework. While the mce remotes obviously map to IR_TYPE_RC6, I've yet to look at what the actual ir signals from the native imon remotes are, so for the moment, imon native ir is mapped to IR_TYPE_OTHER. Nailing it down more accurately is also on the TODO list. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-05-19V4L/DVB: ir-core: add imon pad and mce keymapsJarod Wilson3-0/+299
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-05-19V4L/DVB: ir-core: Add support for badly-implemented hardware decodersMauro Carvalho Chehab2-0/+84
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-05-19V4L/DVB: Break Remote Controller keymaps into modulesMauro Carvalho Chehab66-0/+5628
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>