An error occurred fetching the project authors.
- 30 Jan, 2017 1 commit
-
-
Sean Young authored
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>
-
- 09 Jul, 2016 1 commit
-
-
Jonathan McDowell authored
Fix RC5 decoding with Fintek CIR chipset Commit e87b540b 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=117221Signed-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>
-
- 19 Nov, 2015 1 commit
-
-
Heiner Kallweit authored
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>
-
- 19 Aug, 2015 1 commit
-
-
David Härdeman authored
This reverts commit a0466f15. 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>
-
- 14 May, 2015 1 commit
-
-
James Hogan authored
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>
-
- 30 Oct, 2014 1 commit
-
-
Mauro Carvalho Chehab authored
Changeset e87b540b 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>
-
- 30 Jul, 2014 1 commit
-
-
Mauro Carvalho Chehab authored
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>
-
- 25 Jul, 2014 2 commits
-
-
David Härdeman authored
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>
-
David Härdeman authored
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>
-
- 24 Jul, 2014 1 commit
-
-
David Härdeman authored
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>
-
- 11 Mar, 2014 1 commit
-
-
James Hogan authored
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>
-
- 07 Feb, 2014 1 commit
-
-
Mauro Carvalho Chehab authored
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>
-
- 23 Mar, 2013 1 commit
-
-
David Härdeman authored
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>
-
- 27 Oct, 2012 1 commit
-
-
David Härdeman authored
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>
-
- 31 Oct, 2011 1 commit
-
-
Paul Gortmaker authored
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>
-
- 29 Dec, 2010 5 commits
-
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
Those functions are not InfraRed specific. So, rename them to properly reflect it. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
David Härdeman authored
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>
-
Mauro Carvalho Chehab authored
As protocol decoders are specific to InfraRed, keep their names as-is. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 21 Oct, 2010 1 commit
-
-
Maxim Levitsky authored
Add new event types for timeout & carrier report Move timeout handling from ir_raw_event_store_with_filter to ir-lirc-codec, where it is really needed. Now lirc bridge ensures proper gap handling. Extend lirc bridge for carrier & timeout reports Note: all new ir_raw_event variables now should be initialized like that: DEFINE_IR_RAW_EVENT(ev); To clean an existing event, use init_ir_raw_event(&ev); Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 02 Aug, 2010 3 commits
-
-
David Härdeman authored
This patch moves the state from each raw decoder into the ir_raw_event_ctrl struct. This allows the removal of code like this: spin_lock(&decoder_lock); list_for_each_entry(data, &decoder_list, list) { if (data->ir_dev == ir_dev) break; } spin_unlock(&decoder_lock); return data; which is currently run for each decoder on each event in order to get the client-specific decoding state data. In addition, ir decoding modules and ir driver module load order is now independent. Centralizing the data also allows for a nice code reduction of about 30% per raw decoder as client lists and client registration callbacks are no longer necessary (but still kept around for the benefit of the lirc decoder). Out-of-tree modules can still use a similar trick to what the raw decoders did before this patch until they are merged. 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>
-
David Härdeman authored
With the current logic, each raw decoder needs to add a copy of the exact same sysfs code. This is both unnecessary and also means that (re)loading an IR driver after raw decoder modules have been loaded won't work as expected. This patch moves that logic into ir-raw-event and adds a single sysfs file per device. Reading that file returns something like: "rc5 [rc6] nec jvc [sony]" (with enabled protocols in [] brackets) Writing either "+protocol" or "-protocol" to that file will enable or disable the according protocol decoder. An additional benefit is that the disabling of a decoder will be remembered across module removal/insertion so a previously disabled decoder won't suddenly be activated again. The default setting is to enable all decoders. This is also necessary for the next patch which moves even more decoder state into the central raw decoding structs. 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>
-
Jarod Wilson authored
Rather than registering all IR protocol decoders as enabled when bringing up a new device, only enable the IR protocol decoder that matches the keymap being loaded. Additional decoders can be enabled on the fly by those that need to, either by twiddling sysfs bits or by using the ir-keytable util from v4l-utils. Functional testing done with the mceusb driver, and it behaves as expected, only the rc6 decoder is enabled, keys are all handled properly, etc. Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 May, 2010 12 commits
-
-
David Härdeman authored
This patch implements the agreed upon 1:31 integer encoded pulse/duration struct for ir-core raw decoders. All decoders have been tested after the change. Comments are welcome. Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
David Härdeman authored
This patch adds RC5x support to drivers/media/IR/ir-rc5-decoder.c Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
ir-core.h has the kABI to be used by the bridge drivers, when needing to register IR protocols and pass IR events. However, the same file also contains IR subsystem internal calls, meant to be used inside ir-core and between ir-core and the raw decoders. Better to move those functions to an internal header, for some reasons: 1) Header will be a little more cleaner; 2) It avoids the need of recompile everything (bridge/hardware drivers, etc), just because a new decoder were added, or some other internal change were needed; 3) Better organize the ir-core API, splitting the functions that are internal to IR core and the ancillary drivers (decoders, lirc_dev) from the features that should be exported to IR subsystem clients. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
David Härdeman authored
drivers/media/IR/ir-raw-event.c is currently written with the assumption that all "raw" hardware will generate events only on state change (i.e. when a pulse or space starts). However, some hardware (like mceusb, probably the most popular IR receiver out there) only generates duration data (and that data is buffered so using any kind of timing on the data is futile). Furthermore, using signed int's to represent pulse/space durations is a well-known approach when writing ir decoders. With this patch: - s64 int's are used to represent pulse/space durations in ns - a workqueue is used to decode the ir protocols outside of interrupt context - #defines are added to make decoders clearer - decoder reset is implemented by passing a zero duration to the kfifo queue and decoders are updated accordingly Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Some spinlocks are not properly initialized on ir core: [ 471.714132] BUG: spinlock bad magic on CPU#0, modprobe/1899 [ 471.719838] lock: f92a08ac, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 471.727301] Pid: 1899, comm: modprobe Not tainted 2.6.33 #36 [ 471.733062] Call Trace: [ 471.735537] [<c1498793>] ? printk+0x1d/0x22 [ 471.739866] [<c12694e3>] spin_bug+0xa3/0xf0 [ 471.744224] [<c126962d>] do_raw_spin_lock+0x7d/0x160 [ 471.749364] [<f92a01ff>] ? ir_rc5_register+0x6f/0xf0 [ir_rc5_decoder] So, use static initialization for the static spinlocks, instead of the dynamic ones (currently used), as proposed by David Härdeman on one of his RFC patches. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Reimplement the RC-5 decoder state machine. Code is now clear, and works properly. It is also simpler than the previous implementations. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
A previous cleanup patch removed more than needed. Re-add the logic that disable the decoders. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Now that the decoders are state machine, there's no need to create an ancillary buffer while decoding the protocol. Just call the decoders code directly, event by event. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
This decoder is also based on a state machine, just like the NEC protocol decoder. It is pedantic in the sense that accepts only 14 bits. As there are some variants that outputs less bits, it needs to be improved to also handle those. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Remove dead code and properly name a few constants Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Thanks to Andy Walls <awalls@md.metrocast.net> for pointing me his code, that gave me some ideas to better implement it. After some work with saa7134 bits, I found a way to catch both IRQ edge pulses. By enabling it, the NEC decoder can now take both pulse and spaces into account, making it more precise. Instead of the old strategy of handling the events all at once, this code implements a state machine. Due to that, it handles individual pulse or space events, validating them against the protocol, producing a much more reliable decoding. With the new implementation, the protocol trailer bits are properly handled, making possible for the repeat key to work. Also, the code is now capable of handling both NEC and NEC extended IR devices. With NEC, it produces a 16 bits code, while with NEC extended, a 24 bits code is returned. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
David Härdeman authored
Rewrites the keyup/keydown logic in drivers/media/IR/ir-keytable.c. All knowledge of keystates etc is now internal to ir-keytable.c and not scattered around ir-raw-event.c and ir-nec-decoder.c (where it doesn't belong). In addition, I've changed the API slightly so that ir_input_dev is passed as the first argument rather than input_dev. If we're ever going to support multiple keytables we need to move towards making ir_input_dev the main interface from a driver POV and obscure away the input_dev as an implementational detail in ir-core. Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 18 May, 2010 4 commits
-
-
Mauro Carvalho Chehab authored
With the help of raw_register/raw_unregister, adds a sysfs group associated with the decoder, inside the corresponding irrcv node. Writing 1 to nec_decoder/enabled enables the decoder, while writing 0 disables it. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Some decoders and a lirc_dev interface may need some other operations to work. For example: IR device register/unregister and ir_keydown events may need to be tracked. As some operations can occur in interrupt time, and a lock is needed to prevent un-registering a decode while decoding a key, the lock needed to be convert into a spin lock. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Instead of hardcoding the protocols into ir-core, add a register interface for the IR protocol decoders, and convert ir-nec-decoder into a client of ir-core. With this approach, it is possible to dynamically load the needed IR protocols, and to add a RAW IR interface module, registered as one IR raw protocol decoder. This patch opens a way to register a lirc_dev interface to work as an userspace IR protocol decoder. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
At raw_decode mode, the key is processed after the end of a timer. The previous code resets the timer every time something is received at the IR port. While this works fine with IR's that don't implement repeat, like Avermedia RM-JX IR, it keeps waiting until keydown, on IR's that implement NEC repeat command, like the Terratec yellow. The solution is to change the behaviour to do the timeout after the first received data. The timeout is currently set to 15 ms, as it works fine with NEC protcocol. It may need some adjustments to support other protocols and to better handle spurious detections that may happen with some IR sensors. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-