Currently, they get set up with the pad keytable, which they can't
actually use at all. Also add another variant of volume scancodes from
another 0xffdc device, and properly set up the 0x9e 0xffdc device as an
iMON VFD w/MCE proto IR.
Based on data and a prior patch from Anders Eriksson on the lirc list.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Lest we get our keycodes wrong... Thus far, in practice, I've not found
it to actually matter, but its one of the issues raised in
https://bugzilla.kernel.org/show_bug.cgi?id=16351 that wasn't addressed
by converting to using native IR keydown/up functions.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a stab at separating the mouse (and front panel/knob) events
out to a separate input device. This is necessary in preparation for
the next patch which makes the rc-core input dev opaque to rc
drivers.
I can't verify the correctness of the patch beyond the fact that it
compiles without warnings. The driver has resisted most of my
attempts at understanding it properly...for example, the double calls
to le64_to_cpu() and be64_to_cpu() which are applied in
imon_incoming_packet() and imon_panel_key_lookup() would amount
to a bswab64() call, irregardless of the cpu endianness, and I think
the code wouldn't have worked on a big-endian machine...
- Minor alterations to apply with minimal core IR changes
- Use timer for imon keys too, since its entirely possible for the
receiver to miss release codes (either by way of another key being
pressed while the first is held or by the remote pointing away from
the recevier when the key is release. yes, I know, its ugly).
- Bump driver version number, since this is a fairly significant change
(for the much much better).
Tested successfully w/an imon knob receiver.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The imon driver currently reimplements its own version of ir_keyup
(along with key release timer functionality also already present in the
core IR code). A follow-up imon patch will make use of ir_keyup and the
IR stack's key release code.
Trivial extraction from David Härdeman's pending rc-core merge and
device interface abstraction patchset to facilitate merging a patch
based on his imon input dev split patch ahead of the larger churn, which
is slated for post-2.6.37-rc1 (after Dmitry's large keycode patches are
merged in mainline).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
For some cards, ir_dev->props and ir_dev->raw are both NULL. These cards are
using built-in IR decoding instead of raw, and can't easily be made to switch
protocols.
So upon reading /sys/class/rc/rc?/protocols on such a card, return 'builtin' as
the supported and enabled protocol. Return -EINVAL on any attempts to change
the protocol. And most important of all, don't crash.
Signed-off-by: Brian Rogers <brian@xyzw.org>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
The logic in ir_timer_keyup was inverted.
In case that values aren't equal,
the meaning of the time_is_after_eq_jiffies(ir->keyup_jiffies) is that
ir->keyup_jiffies is after the the jiffies or equally that
that jiffies are before the the ir->keyup_jiffies which is
exactly the situation we want to avoid (that the timeout is in the future)
Confusing Eh?
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Anton Blanchard <anton@samba.org>, double IR events on
2.6.36-rc2 and a DViCO FusionHDTV DVB-T Dual Express are happening:
[ 1351.032084] ir_keydown: i2c IR (FusionHDTV): key down event, key 0x0067, scancode 0x0051
[ 1351.281284] ir_keyup: keyup key 0x0067
ie one key down event and one key up event 250ms later.
So, we need to increase the repeat timeout, to avoid this bug to hit.
As we're doing it at core, this fix is not needed anymore at dib0700 driver.
Thanks-to: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reported in lirc sf.net tracker and on lirc mailing list
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The original code dereferenced ir->raw after freeing it and setting it
to NULL.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
"ir_dev->props" can be NULL. We only use raw mode if "ir_dev->props" is
non-NULL and "ir_dev->props->driver_type == RC_DRIVER_IR_RAW".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
Add latest unported version of this driver to media/IR.
Next patch will port it to ir core.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This way it is possible to use evtest to create keymap for unknown remote.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
LIRC: add new IOCTL that enables learning mode (wide band receiver)
Still missing features: carrier report & timeout reports.
Will need to pack these into ir_raw_event
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some ir input devices have small buffer, and interrupt the host
each time it is full (or half full)
Add a helper that automaticly handles timeouts, and also
automaticly merges samples of same time (space-space)
Such samples might be placed by hardware because size of
sample in the buffer is small (a byte for example).
Also remove constness from ir_dev_props, because it now contains timeout
settings that driver might want to change
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
This adds support for repeat detecting for NECX variant
Tested with uneversal remote
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Repeat space is 4 units, not 8.
Current code would never trigger a repeat.
However that isn't true for NECX, so repeat there
must be handled differently.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Reviewed-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, jvc decoder will attempt misdetect next press as a repeat
of last keypress, therefore second keypress isn't detected.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is perfectly possible to have ir_raw_event_work
running concurently on two cpus, thus we must protect
it from that situation.
This stems from the fact that if hardware sends short packets of samples
we might end up queueing the work item more times that nessesary.
Such job isn't well suited for a workqueue, so use a kernel thread.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some handlers (lirc for example) allocates memory on initialization,
doing so in atomic context is cumbersome.
Fixes warning about sleeping function in atomic context.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always be pulse
* Make TO_US macro actualy print what it should.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move IR drives below separate menu.
This allows to disable them.
Also correct a typo.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Moves drivers/staging/lirc/lirc_streamzap.c to
drivers/media/IR/streamzap.c, along with making the requisite Kconfig
and Makefile changes.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in mceusb_init_input_dev was being overwritten by the correct
one shortly after it was initialized (ultimately resulting in a memory
leak). This bug was inherited from imon.c, and was pointed out to me by
Maxim Levitsky.
v2: fix incorrect dev arg to dev_dbg
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in imon_init_idev was being overwritten by the correct one
shortly after it was initialized (ultimately resulting in a memory
leak). Additionally, there was an ill-advised memcpy into that
extraneous ir_input_dev which gets fixed by this.
Ill-advised memcpy pointed out by Dmitry Torokhov, bad usage of
ir_input_dev pointed out by Maxim Levitsky.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Per Dmitry Torokhov, following input_unregister_device with an
input_free_device is forbidden, the former is sufficient alone.
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rewrites the siano IR implementation. The previous implementation were
non-standard. As such, it has issues if more than one device registers IR,
as there used to have some static constants used during protocol decoding
phase. Also, it used to implement its on RAW decoder, and only for RC5.
The new code uses RC core subsystem for handling IR. This brings several
new features to the driver, including:
- Allow to dynamically replace the IR keycodes;
- Supports all existing raw decoders (JVC, NEC, RC-5, RC-6, SONY);
- Supports lirc dev;
- Doesn't have race conditions when more than one sms IR is
registered;
- The code size for the IR implementation is very small;
- it exports the IR features via /sys/class/rc.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
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>
There is a typo here. We meant to test "rbuf" instead of "drv". We
already tested "drv" earlier.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The lirc userspace needs all the current ioctls defined, and we need to
put the header files in places out-of-tree and/or staging lirc drivers
(which I plan to prep soon) can easily build with. I've actually tested this
in a tree w/all the lirc drivers queued up to be submitted for staging. I'm
also reasonably sure that Andy Walls is going to need most of the ioctls
anyway for his cx23888 IR driver work.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Spent a while last night getting device initialization packet captures
under Windows for all generations of devices. There are a few places
where we were doing things differently, and few things we were doing
that we don't need to do, particularly on gen3 hardware, and I *think*
one of those things is what was locking up my pinnacle hw from time to
time -- at least, its been perfectly well behaved every time its been
plugged in since making this change.
First up, we're adding a bit more to the gen1 init routine here. Its
not absolutely necessary, the hardware works the same both with and
without it, but I'd like to be consistent w/Windows here.
Second, DEVICE_RESET is never called when initializing either of my
gen3 devices, its only called for gen1 and gen2. The bits in the gen3
init after removing that, are safe (and interesting) to run on all
hardware, so there's no more gen3-specific init done, there's instead
a generic mceusb_get_parameters() that is run for all hardware.
Third, the gen3 flag isn't needed. We only care if hardware is gen3
during probe, so I've dropped that from the device flags struct.
Successfully tested on all three generations of mceusb hardware.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Prior init unification/simplification patch made these unused, forgot
to remove them, so this silences:
drivers/media/IR/mceusb.c: In function ‘mceusb_gen1_init’:
drivers/media/IR/mceusb.c:769: warning: unused variable ‘partial’
drivers/media/IR/mceusb.c:768: warning: unused variable ‘i’
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
New code should not rely on the big kernel lock,
so use the unlocked_ioctl file operation in lirc.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ir-jvc-decoder uses bitreverse interfaces, so it should select
BITREVERSE.
ir-jvc-decoder.c:(.text+0x550bc): undefined reference to `byte_rev_table'
ir-jvc-decoder.c:(.text+0x550c6): undefined reference to `byte_rev_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Wed, Jul 07, 2010 at 02:52:58PM +0200, Jiri Slaby wrote:
> Hi,
>
> stanse found a locking error in lirc_dev_fop_read:
> if (mutex_lock_interruptible(&ir->irctl_lock))
> return -ERESTARTSYS;
> ...
> while (written < length && ret == 0) {
> if (mutex_lock_interruptible(&ir->irctl_lock)) { #1
> ret = -ERESTARTSYS;
> break;
> }
> ...
> }
>
> remove_wait_queue(&ir->buf->wait_poll, &wait);
> set_current_state(TASK_RUNNING);
> mutex_unlock(&ir->irctl_lock); #2
>
> If lock at #1 fails, it beaks out of the loop, with the lock unlocked,
> but there is another "unlock" at #2.
This should do the trick. Completely untested beyond compiling, but its
not exactly a complicated fix, and in practice, I'm not aware of anyone
ever actually tripping that locking bug, so there's zero functional change
in typical use here.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Started out as an effort to try to tackle the last remaining issue I'm
having with this damned pinnacle device getting wedged the first time
its plugged in after an indeterminate length of not being plugged in.
Didn't get that solved yet, but did streamline the init code a bit more
and remove some superfluous gunk. Nukes a completely unneeded call to
usb_device_init() and several lines of overly complex crap in the gen1
device init path.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
