The rc5 protocol does not have a leading pulse or space, but we encode
the first bit using a single leading pulse. For other protocols, the
leading pulse or space does not represent any bit. So, don't remove the
first bit if a leading pulse is present.
Cc: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The IR rc6 encoder sends the header using manchester encoding using 0
bits, which causes the following:
UBSAN: Undefined behaviour in drivers/media/rc/rc-ir-raw.c:247:6
shift exponent 4294967295 is too large for 64-bit type 'long long unsigned int'
So, allow the leader code to send a pulse and space and remove the unused
pulse_space_start field.
Cc: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
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>
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>
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>
Add the capability to encode RC-5, RC-5X and RC-5-SZ scancodes as raw
events.
The Manchester modulation helper is used, and for RC-5X it is used twice
with two sets of timings, the first with a short trailer space for the
space in the middle, and the second with no leader so that it can
continue the space.
The encoding in RC-5-SZ first inserts a pulse and then simply utilizes
the generic Manchester encoder available in rc-core.
Signed-off-by: James Hogan <james@albanarts.com>
Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There are many variants of extended rc5. This implements the 20 bit
version.
Signed-off-by: Sean Young <sean@mess.org>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The 2nd stop bit in rc5 is reused as an inverted 6th command bit in
20 bits rc5x. Currently the rc5x decoder sets the 6th command bit as
an inverted duplicate of the lowest system bit; as a result we do
not have all the command bits.
Note that there are no rc5x keymaps present.
Signed-off-by: Sean Young <sean@mess.org>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Fix RC5 decoding with Fintek CIR chipset
Commit e87b540be2 tightened up the RC5
decoding by adding a check for trailing silence to ensure a valid RC5
command had been received. Unfortunately the trailer length checked was
10 units and the Fintek CIR device does not want to provide details of a
space longer than 6350us. This meant that RC5 remotes working on a
Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening
the trailer check to 6 units (allowing for a previous space in the
received remote command).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221
Signed-off-by: Jonathan McDowell <noodles@earth.li>
Cc: stable@vger.kernel.org
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
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>
This reverts commit a0466f15b4.
The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add the capability to encode RC-5, RC-5X and RC-5-SZ scancodes as raw
events. The protocol is chosen based on the specified protocol mask,
and whether all the required bits are set in the scancode mask, and
none of the unused bits are set in the scancode data. For example a
scancode filter with bit 16 set in both data and mask is unambiguously
RC-5X.
The Manchester modulation helper is used, and for RC-5X it is used twice
with two sets of timings, the first with a short trailer space for the
space in the middle, and the second with no leader so that it can
continue the space.
The encoding in RC-5-SZ first inserts a pulse and then simply utilizes
the generic Manchester encoder available in rc-core.
Signed-off-by: James Hogan <james@albanarts.com>
Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Changeset e87b540be2 broke RC5-SZ decoding, as it forgot to add
the extra bit check for the enabled protocols at the beginning of
the logic.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The IR dprintk message that prints a RC5 decoding failure
is not much helpful, as it doesn't tell on what bit the
error occurred.
Add such information, in order to make the debug message
more useful.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions that I've
seen with e.g. Sony protocols).
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
