summaryrefslogtreecommitdiffstats
path: root/drivers/media/rc/ir-nec-decoder.c
AgeCommit message (Collapse)AuthorFilesLines
2018-04-20media: rc: set timeout to smallest value required by enabled protocolsSean Young1-0/+1
The longer the IR timeout, the longer the rc device waits until delivering the trailing space. So, by reducing this timeout, we reduce the delay for the last scancode to be delivered. Note that the lirc daemon disables all protocols, in which case we revert back to the default value. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-02-14media: rc: replace IR_dprintk() with dev_dbg in IR decodersSean Young1-11/+9
Use dev_dbg() rather than custom debug function. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-14media: lirc: use the correct carrier for scancode transmitSean Young1-0/+1
If the lirc device supports it, set the carrier for the protocol. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-11media: rc: add SPDX identifiers to the code I wroteMauro Carvalho Chehab1-14/+5
As we're now using SPDX identifiers, on the several media drivers I wrote, add the proper SPDX, identifying the license I meant. As we're now using the short license, it doesn't make sense to keep the original license text. Also, fix MODULE_LICENSE to properly identify GPL v2. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-11-27media: ir-nec-decoder: fix kernel-doc parametersMauro Carvalho Chehab1-2/+1
Some parameters aren't correctly identified, as noticed by those warnings: drivers/media/rc/ir-nec-decoder.c:49: warning: No description found for parameter 'ev' drivers/media/rc/ir-nec-decoder.c:49: warning: Excess function parameter 'duration' description in 'ir_nec_decode' drivers/media/rc/ir-nec-decoder.c:189: warning: Excess function parameter 'raw' description in 'ir_nec_scancode_to_raw' Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-10-11media: rc: nec decoder should not send both repeat and keycodeSean Young1-12/+17
When receiving an nec repeat, rc_repeat() is called and then rc_keydown() with the last decoded scancode. That last call is redundant. Fixes: 265a2988d202 ("media: rc-core: consistent use of rc_repeat()") Cc: <stable@vger.kernel.org> # v4.14 Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-08-20media: rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_*Sean Young1-8/+9
RC_TYPE is confusing and it's just the protocol. So rename it. Suggested-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sean Young <sean@mess.org> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-08-20media: rc: ir-nec-decoder: move scancode composing code into a shared functionShawn Guo1-29/+3
The NEC scancode composing and protocol type detection in ir_nec_decode() is generic enough to be a shared function. Let's create an inline function in rc-core.h, so that other remote control drivers can reuse this function to save some code. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-08-20media: rc-core: consistent use of rc_repeat()David Härdeman1-7/+3
The NEC decoder and the Sanyo decoders check if dev->keypressed is true before calling rc_repeat (without holding dev->keylock). Meanwhile, the XMP and JVC decoders do no such checks. This patch makes sure all users of rc_repeat() do so consistently by removing extra checks in NEC/Sanyo and modifying the check a bit in rc_repeat() so that no input event is generated if the key isn't pressed. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-01-30[media] rc: ir-nec-decoder: Add encode capabilityJames Hogan1-0/+81
Add the capability to encode NEC scancodes as raw events. The scancode_to_raw is pretty much taken from the img-ir NEC filter() callback, and modulation uses the pulse distance helper added in a previous commit. Signed-off-by: James Hogan <james@albanarts.com> Signed-off-by: Sean Young <sean@mess.org> Cc: Antti Seppälä <a.seppala@gmail.com> Cc: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-01-30[media] rc: unify nec32 protocol scancode formatSean Young1-1/+4
There are two different encodings used for nec32: - The ir-nec-decoder.c decoder treats it as 32 bit msb first. - The img-ir decoder/encoder, winbond wakeup, dib0700, ir-ctl userspace, treat nec32 analogous to necx and nec: 4 bytes, each lsb first. So this format reverses the 4 bytes. There are arguments to be had for both formats, but we should not use different formats in different parts of the kernel. Selecting the second format introduces the least code churn. It does mean that the TiVo keymap needs updating. This change was submitted before as "18bc174 [media] media: rc: change 32bit NEC scancode format", which was reverted because it was unclear what scancode rc drivers produce. There are now more examples of drivers which produce nec32 in lsb format. The TiVo keymap is verified against the Nero Liquid TiVo remote. The keymap is not for the Tivo DVR remote, which uses rc-5. Signed-off-by: Sean Young <sean@mess.org> Cc: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22[media] rc: split nec protocol into its three variantsSean Young1-2/+6
Currently we do not know what variant (bit length) of the nec protocol is used, other than from guessing from the length of the scancode. Now nec will be handled the same way as the sony protocol or the rc6 protocol; one variant per bit length. In the future we might want to expose the rc protocol type to userspace and we don't want to be introducing this world of pain into userspace too. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2015-11-19[media] media: rc: move check whether a protocol is enabled to the coreHeiner Kallweit1-3/+0
Checking whether a protocol is enabled and calling the related decoder functions should be done by the rc core, not the protocol handlers. Properly handle lirc considering that no protocol bit is set for lirc. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-07-25[media] rc-core: remove protocol arraysDavid Härdeman1-1/+1
The basic API of rc-core used to be: dev = rc_allocate_device(); dev->x = a; dev->y = b; dev->z = c; rc_register_device(); which is a pretty common pattern in the kernel, after the introduction of protocol arrays the API looks something like: dev = rc_allocate_device(); dev->x = a; rc_set_allowed_protocols(dev, RC_BIT_X); dev->z = c; rc_register_device(); There's no real need for the protocols to be an array, so change it back to be consistent (and in preparation for the following patches). [m.chehab@samsung.com: added missing changes at some files] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-07-23[media] rc-core: document the protocol typeDavid Härdeman1-1/+1
Right now the protocol information is not preserved, rc-core gets handed a scancode but has no idea which protocol it corresponds to. This patch (which required reading through the source/keymap for all drivers, not fun) makes the protocol information explicit which is important documentation and makes it easier to e.g. support multiple protocols with one decoder (think rc5 and rc-streamzap). The information isn't used yet so there should be no functional changes. [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-04-06[media] rc-core: do not change 32bit NEC scancode format for nowDavid Härdeman1-4/+1
This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2 and changes the code at img-ir-nec.c to use the order used by the other NEC decoders. The original patch ignored the fact that NEC32 scancodes are generated not only in the NEC raw decoder but also directly in some drivers. Whichever approach is chosen it should be consistent across drivers and this patch needs more discussion. Furthermore, I'm convinced that we have to stop playing games trying to decipher the "meaning" of NEC scancodes (what's the customer/vendor/address, which byte is the MSB, etc). Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-11[media] rc: abstract access to allowed/enabled protocolsJames Hogan1-1/+1
The allowed and enabled protocol masks need to be expanded to be per filter type in order to support wakeup filter protocol selection. To ease that process abstract access to the rc_dev::allowed_protos and rc_dev::enabled_protocols members with inline functions. Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-07[media, edac] Change my email addressMauro Carvalho Chehab1-2/+2
There are several left overs with my old email address. Remove their occurrences and add myself at CREDITS, to allow people to be able to reach me on my new addresses. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-06[media] media: rc: change 32bit NEC scancode formatJames Hogan1-1/+4
Change 32bit NEC scancode format (used by Apple and TiVo remotes) to encode the data with the correct bit order. Previously the raw bits were used without being bit reversed, now each 16bit half is bit reversed compared to before. So for the raw NEC data: (LSB/First) 0xAAaaCCcc (MSB/Last) (where traditionally AA=address, aa=~address, CC=command, cc=~command) We now generate the scancodes: (MSB) 0x0000AACC (LSB) (normal NEC) (MSB) 0x00AAaaCC (LSB) (extended NEC, address check wrong) (MSB) 0xaaAAccCC (LSB) (32-bit NEC, command check wrong) Note that the address byte order in 32-bit NEC scancodes is different to that of the extended NEC scancodes. I chose this way as it maintains the order of the bits in the address/command fields, and CC is clearly intended to be the LSB of the command if the TiVo codes are anything to go by so it makes sense for AA to also be the LSB. The TiVo keymap is updated accordingly. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Jarod Wilson <jarod@redhat.com> Cc: linux-media@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-03-23[media] rc-core: don't treat dev->rc_map.rc_type as a bitmapDavid Härdeman1-1/+1
store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for two reasons. First of all, it is pretty bogus to change the protocol type of the keymap just because the hardware has been asked to decode a different protocol. Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed out by James Hogan <james.hogan@imgtec.com>. Fix both issues by introducing a separate enabled_protocols member to struct rc_dev. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-27[media] rc-core: add separate defines for protocol bitmaps and numbersDavid Härdeman1-2/+2
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-08-11[media] nec-decoder: fix NEC decoding for Pioneer Laserdisc CU-700 remoteSean Young1-2/+2
This remote sends a header pulse of 8150us followed by a space of 4000us. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-11-23Merge tag 'v3.2-rc2' into staging/for_v3.3Mauro Carvalho Chehab1-0/+1
* tag 'v3.2-rc2': (3068 commits) Linux 3.2-rc2 hfs: add sanity check for file name length fsl-rio: fix compile error blackfin: Fixup export.h includes Blackfin: add serial TX IRQ in individual platform resource virtio-pci: fix use after free ACPI / cpuidle: Remove acpi_idle_suspend (to fix suspend regression) drm/radeon/kms/combios: fix dynamic allocation of PM clock modes [CPUFREQ] db8500: fix build error due to undeclared i variable bma023: Add SFI translation for this device vrtc: change its year offset from 1960 to 1972 ce4100: fix a build error arm/imx: fix imx6q mmc error when mounting rootfs arm/imx: fix AUTO_ZRELADDR selection arm/imx: fix the references to ARCH_MX3 ARM: mx51/53: set pwm clock parent to ipg_perclk btrfs: rename the option to nospace_cache drm/radeon/kms/pm: switch to dynamically allocating clock mode array drm/radeon/kms: optimize r600_pm_profile_init drm/radeon/kms/pm: add a proper pm profile init function for fusion ... Conflicts: drivers/media/radio/Kconfig
2011-11-23[media] ir-nec-decoder: Report what bit failed at debug msgMauro Carvalho Chehab1-2/+2
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-10-31drivers/media: Add module.h to all files using it implicitlyPaul Gortmaker1-0/+1
A pending cleanup will mean that module.h won't be implicitly everywhere anymore. Make sure the modular drivers in clocksource are actually calling out for <module.h> explicitly in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-03-22[media] rc: interim support for 32-bit NEC-ish scancodesJarod Wilson1-2/+8
The Apple and TiVo remotes I've got use an NEC-ish protocol, but rather than a command/not_command pair, they have what appear to be vendor ID bytes. This change makes the NEC decoder warn if the command/not_command checksum fails, but then passes along a full 32-bit scancode for keymap lookup. This change should make no difference for existing keymaps, since they simply won't have 32-bit scancodes, but allows for a 32-bit keymap. At the moment, that'll have to be uploaded by the user, but I've got Apple and TiVo remote keymaps forthcoming. In the long run (2.6.40, hopefully), we should probably just always use all 32 bits for all NEC keymaps, but this should get us by for 2.6.39. (Note that a few of the TiVo keys actuallly *do* pass the command checksum, so for now, the keymap for this remote will have to be a mix of 24-bit and 32-bit scancodes, but so be it). Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-31[media] ir-nec-decoder: fix repeat key issueMariusz Białończyk1-3/+7
Fixing the problem with NEC protocol and repeating keys under the following circumstances. The problem occurs when there is a repeat code without properly decoded scancode. This leads to repeat the wrong (last decoded) scancode. An example from real life: I am pressing volume down, then several minutes later i am pressing volume up, but the real scancode is wrongly decoded and only a repeat event is emitted, so as a result volume is going down while i am holding volume up button. The patch fixes above problem using rc_keyup timeout (as pointed by Mauro). It just prevents key repeats if they appear after rc_keyup. Signed-off-by: Mariusz Białończyk <manio@skyboo.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-29[media] rc: Rename remote controller type to rc_type instead of ir_typeMauro Carvalho Chehab1-2/+2
for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,IR_TYPE,RC_TYPE,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_type,rc_type,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-29[media] Rename all public generic RC functions from ir_ to rc_Mauro Carvalho Chehab1-3/+3
Those functions are not InfraRed specific. So, rename them to properly reflect it. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-29[media] ir-core: make struct rc_dev the primary interfaceDavid Härdeman1-8/+7
This patch merges the ir_input_dev and ir_dev_props structs into a single struct called rc_dev. The drivers and various functions in rc-core used by the drivers are also changed to use rc_dev as the primary interface when dealing with rc-core. This means that the input_dev is abstracted away from the drivers which is necessary if we ever want to support multiple input devs per rc device. The new API is similar to what the input subsystem uses, i.e: rc_device_alloc() rc_device_free() rc_device_register() rc_device_unregister() [mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts] Signed-off-by: David Härdeman <david@hardeman.nu> Acked-by: Jarod Wilson <jarod@redhat.com> Tested-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-29[media] Rename rc-core files from ir- to rc-Mauro Carvalho Chehab1-1/+1
As protocol decoders are specific to InfraRed, keep their names as-is. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-12-29[media] rename drivers/media/IR to drives/media/rcMauro Carvalho Chehab1-0/+217
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>