Due to commit cdda911c34, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.
For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.
Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).
Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any functional difference until the referenced
change went into the input layer.
input_sync once per IR signal. There was another hidden bug in the code
where we were calling input_report_key using last_keycode instead of our
just discovered keycode, which manifested with the reordering of calling
input_report_key and setting last_keycode.
Reported-by: Stephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: Jeff Brown <jeffbrown@android.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While 0xffdc devices have their IR protocol hard-coded into the firmware
of the device, we have no known way of telling what it is if we don't
have the device's config byte already in the driver. Unknown devices
default to the imon native protocol, but might actually be rc6, so we
should set the driver up such that the user can load the rc6 keytable
from userspace and still have a working device ahead of its config byte
being added to the driver.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Another device with the 0xffdc device id, this one with 0x7e in the
config byte. Its an iMON VFD + RC6 IR, in a CoolerMaster 260 case.
Reported-by: Filip Streibl <filip@streibl.cz>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.
To fix this, I've lowered the "send a reset event" logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.
CC: stable@kernel.org
CC: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.
The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.
This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.
Tested-by: Matthijs van Drunen
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As pointed out on the lirc list by Andreas Dick, initial panel key
repeat suppression wasn't working, as we had no timevals accumulated
until after the first repeat. Also add a missing locking call.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Courtesy of information from Andreas Dick on the lirc list.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Petter Selasky pointed out to me that we're leaking urbs when
mce_async_out is called. Its used both for configuring the hardware and
for transmitting IR data. In the tx case, mce_request_packet actually
allocates both a urb and the transfer buffer, neither of which was being
torn down. Do that in the tx callback.
CC: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was a missing lock in fintek_suspend. Without the lock, its
possible the system will be in the middle of receiving IR (draining the
RX buffer) when we try to disable CIR interrupts.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Store the cdev pointer in struct irctl, allocated dynamically as needed,
rather than having a static array. At the same time, recycle some of the
saved memory to nudge the maximum number of lirc devices supported up a
ways -- its not that uncommon these days, now that we have the rc-core
lirc bridge driver, to see a system with at least 4 raw IR receivers.
(consider a mythtv backend with several video capture devices and the
possible need for IR transmit hardware).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Aside from the initial "hey, lets make sure we've flushed any
pre-existing data on the device" call to mce_sync_in, every other one of
the calls was entirely superfluous. Ergo, remove them all, and rename
the one and only (questionably) useful one to reflect what it really
does. Verified on both gen2 and gen3 hardware to make zero difference.
Well, except that you no longer get a bunch of urb submit failures from
the unneeded mce_sync_in calls. Oh. And move that flush to a point
*after* we've wired up the inbound urb, or it won't do squat. I have
half a mind to just remove it entirely, but someone thought it was
necessary at some point, and it doesn't seem to hurt, so lets leave it
for the time being.
This excercise took place due to insightful questions asked by Hans
Petter Selasky, about the possible reuse of the inbound urb before it
was actually availble by mce_sync_in, so thanks to him for motivating
this cleanup.
Reported-by: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's an SMK-device-id remote kit from I-O Data avaiable primarily in
Japan, which appears to have no tx hardware, but has rx functionality
that works with the mceusb driver by simply adding its device ID.
Reported-by: Jeremy Kwok <jeremykwok@desu.ca>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Using dev_dbg is more complexity than many users are able to deal with.
Make it easier to get debug spew feedback from them by adding an mce_dbg
printk macro that spews using dev_info when debug=1 is set for the
mceusb module.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
driver to use dvb-usb-remote.
The remote(s) generates 24 bit NEC codes, lme2510 keymaps redefined.
Other minor fixes
fix le warning.
make sure frontend is detached on firmware change.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a new driver for the Fintek LPC SuperIO CIR function, in the
Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so
thanks go to them for supporting this effort.
This driver started out as a copy of the nuvoton-cir driver, and was
then modified as needed for the Fintek chip. The two share many
similaries, though the buffer handling for the Fintek chip is actually
nearly identical to the mceusb buffer handling, so the parser routine is
almost a drop-in copy of the mceusb buffer parser (a candidate for being
abstracted out into shared code at some point).
This initial code drop *only* supports receive, but the hardware does
support transmit as well. I really haven't even started to look at
what's required, but my guess is that its also pretty similar to mceusb.
Most people are probably only really interested in RX anyway though, so
I think its good to get this out there even with only RX.
(Nb: there are also Fintek-made mceusb receivers, which presumably, this
chip shares CIR hardware with).
This hardware can be found on at least Jetway NC98 boards and derivative
systems, and likely others as well. Functionality was tested with an
NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge)
and NEC-ish (tivo) remotes all successful, as was lirc userspace decode
of the RC6 remote.
CC: Aaron Huang <aaron_huang@fintek.com.tw>
CC: Tom Tsai <tom_tsai@fintek.com.tw>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The default REP_PERIOD is 33 ms. This doesn't make sense for IR's,
as, in general, an IR repeat scancode is provided at every 110/115ms,
depending on the RC protocol. So, increase its default, to do a
better job avoiding ghost repeat events.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
ictx->touch is intialied in imon_init_intf1, to the result of calling the
function that contains this code. Thus, in this code, input_free_device
should be called on touch itself.
A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
local idexpression struct input_dev * x;
expression ra,rr;
position p1,p2;
@@
x = input_allocate_device@p1(...)
... when != x = rr
when != input_free_device(x,...)
when != if (...) { ... input_free_device(x,...) ...}
if(...) { ... when != x = ra
when forall
when != input_free_device(x,...)
\(return <+...x...+>; \| return@p2...; \) }
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
cocci.print_main("input_allocate_device",p1)
cocci.print_secs("input_free_device",p2)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a new rc-core device driver for the IR transceivers made by
RedRat Ltd. (http://redrat.co.uk/). It started out life as an
out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge,
by Stephen Cox. He started porting it to what was then ir-core, and I
finally picked it up about two week ago and did a fairly large overhaul
on it, and its now into a state where I'm fairly comfortable submitting
it here for review and inclusion in the kernel. I'm claiming authorship
of this driver, since while it started out as Stephen's work, its
definitely a derivative work now, at 876 lines added and 1698 lines
removed since grabbing it from sourceforge. Stephen's name is retained
as secondary author though, and credited in the headers. Those
interested in seeing how the changes evolved can (at least for now) look
at this branch in my git tree:
http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3
That won't be around forever though, and I'm doing this as a single
commit to go into mainline. Anyway...
I've successfully tested in-kernel decode of rc5, rc6 and nec remotes,
as well as lirc userspace decode of rc5 and rc6. There are still some
quirks here to sort out with rc5 lirc userspace decode, but I'm working
with the RedRat folks themselves to figure out what's going on there
(rc5 lirc decode works, but you only get an event on key release --
in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of
rc6 is working perfectly. Transmit is also working, tested by pointing
the redrat3 at an mceusb transceiver, which happily picked up the
transmitted signals and properly decoded them.
There's no default remote for this hardware, so its somewhat arbitrarily
set to use the Hauppauge RC5 keymap by default. Easily changed out by
way of ir-keytable and irrelevant if you're using lircd for decode.
CC: Chris Dodge <chris@redrat.co.uk>
CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk>
CC: Stephen Cox <scox_nz@yahoo.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Continuing with IR transmit after resuming from suspend seems fairly
useless, given that the only place we can actually end up suspending is
after IR has been send and we're simply mdelay'ing. Lets simplify the
resume path by just waiting on tx to complete in the suspend path, then
we know we can't be transmitting on resume, and reinitialization of the
hardware registers becomes more straight-forward.
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was some rather odd spacing in a few of the ite8709-specific
functions that made it hard to read those sections of code. This is just
a simple reformatting.
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just recently acquired an Asus Eee Box PC with an onboard IR receiver
driven by ite-cir (ITE8713 sub-variant). Works out of the box with the
ite-cir driver in 2.6.39, but stops working after a suspend/resume
cycle. Its fixed by simply reinitializing registers after resume,
similar to what's done in the nuvoton-cir driver. I've not tested with
any other ITE variant, but code inspection suggests this should be safe
on all variants.
Reported-by: Stephan Raue <sraue@openelec.tv>
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Eliminate a possible circular locking lockdep warning
- Make sure we don't try to unregister a vfd on a device w/a vga screen
- Always free imon context after devices are removed (display_close can
just error out w/no context)
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Set a default timeout (matching mceusb.c) and use
ir_raw_event_store_with_filter, which leads to better behavior when
using lirc userspace decoding with this hardware
- Fill in rx_resolution with the value we're using here (50us)
- Wire up input phys and device parent pointer
- Use device_init_wakeup() instead of device_set_wakeup_*()
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Using ir_raw_event_store_with_filter() saves about 20 lines of code.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If an IR command is sent (using the LIRC userspace) to rc-loopback
which doesn't include a trailing space, the result is that the message
won't be completely decoded. In addition, "leftovers" from a previous
transmission can be left until the next one. Fix this by faking a long
silence after the end of TX data.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds preliminary IR TX capabilities to the
winbond-cir driver.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Using bool instead of an int helps readability a bit.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Per hardware provided to me, the Formosa Industrial Computing eHome
Infrared Receiver, 0x147a:0xe017, has no tx capability, it is rx only.
Thanks go to Paul Rae for the hardware.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to some excellent investigative work by Douglas Clowes, it was
uncovered that the older w83667hg Nuvoton chip functions with this
driver after actually enabling the CIR function via its multi-function
chip config register. The CIR and CIR wide-band sensor enable bits are
just in a different place on this hardware, so we only poke register
0x27 on 677 hardware now, and we poke register 0x2c on the 667 now.
Reported-by: Douglas Clowes <dclowes1@optusnet.com.au>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are additional chip IDs that report a PNP ID of NTN0530, which we
were refusing to load on. Instead, lets just warn if we encounter an
unknown chip, as there's a chance it will work just fine.
Also, expand the list of known hardware to include both an earlier and a
later generation chip that this driver should function with. Douglas has
an older w83667hg variant, that with a touch more work, will be
supported by this driver, and Lutz has a newer w83677hg variant that
works without any further modifications to the driver.
Reported-by: Douglas Clowes <dclowes1@optusnet.com.au>
Reported-by: Lutz Sammer <johns98@gmx.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the newly introduced KEY_IMAGES where appropriate, and standardize
on KEY_MEDIA for media center/application launcher button (such as the
Windows logo key on the Windows Media Center Ed. remotes).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] ngene: Fix CI data transfer regression Fix CI data transfer regression introduced by previous cleanup.
[media] v4l: make sure drivers supply a zeroed struct v4l2_subdev
[media] Missing frontend config for LME DM04/QQBOX
[media] rc_core: avoid kernel oops when rmmod saa7134
[media] imon: add conditional locking in change_protocol
[media] rc: show RC_TYPE_OTHER in sysfs
[media] ite-cir: modular build on ppc requires delay.h include
[media] mceusb: add Dell transceiver ID
The following is a patch to avoid a kernel oops when running rmmod
saa7134 on kernel 2.6.27.1. The change is as suggested by mchehab on
irc.freenode.org
Signed-off-by: Hussam Al-Tayeb <ht990332@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.
In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.
Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.
With a lock-debugging-enabled kernel, I was getting this:
[ 15.014153] =====================================
[ 15.015048] [ BUG: bad unlock balance detected! ]
[ 15.015048] -------------------------------------
[ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[ 15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10
[ 15.015048] but there are no more locks to release!
[ 15.015048]
[ 15.015048] other info that might help us debug this:
[ 15.015048] 2 locks held by ir-keytable/773:
[ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144
[ 15.015048] #1: (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144
[ 15.015048]
[ 15.015048] stack backtrace:
[ 15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[ 15.015048] Call Trace:
[ 15.015048] [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5
[ 15.015048] [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263
[ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4
[ 15.015048] [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125
[ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon]
[ 15.015048] [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263
[ 15.015048] [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon]
[ 15.015048] [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core]
[ 15.015048] [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22
[ 15.015048] [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144
...
The original report that led to the investigation was the following:
[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd D ffff88010fcd89c8 0 8460 1 0x00000000
[ 1679.457312] ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314] 00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316] ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324] [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
[ 1679.457327] [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330] [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335] [<ffffffff813b0c41>] mutex_lock+0x11/0x30
[ 1679.457338] [<ffffffffa0d54216>] display_open+0x66/0x130 [imon]
[ 1679.457345] [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
[ 1679.457349] [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
[ 1679.457350] [<ffffffff8113d93d>] __dentry_open+0x10d/0x370
[ 1679.457352] [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0
...
Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.
CC: stable@kernel.org
Reported-by: Benjamin Hodgetts <ben@xnode.org>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Stop including <linux/delay.h> in x86 header files which don't
need it. This will let the compiler complain when this header is
not included by source files when it should, so that
contributors can fix the problem before building on other
architectures starts to fail.
Credits go to Geert for the idea.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: James E.J. Bottomley <James.Bottomley@suse.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
LKML-Reference: <20110325152014.297890ec@endymion.delvare>
[ this also fixes an upstream build bug in drivers/media/rc/ite-cir.c ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fix the following compile failure:
drivers/media/rc/ite-cir.c: In function 'ite_decode_bytes':
drivers/media/rc/ite-cir.c:190: error: implicit declaration of function 'generic_find_next_le_bit'
drivers/media/rc/ite-cir.c:199: error: implicit declaration of function 'generic_find_next_zero_le_bit'
Caused by commit 620a32bba4 ("[media] rc: New rc-based ite-cir driver
for several ITE CIRs") interacting with commit c4945b9ed4
("asm-generic: rename generic little-endian bitops functions").
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (442 commits)
[media] videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t
[media] sh_mobile_ceu_camera: Do not call vb2's mem_ops directly
[media] V4L: soc-camera: explicitly require V4L2_BUF_TYPE_VIDEO_CAPTURE
[media] v4l: soc-camera: Store negotiated buffer settings
[media] rc: interim support for 32-bit NEC-ish scancodes
[media] mceusb: topseed 0x0011 needs gen3 init for tx to work
[media] lirc_zilog: error out if buffer read bytes != chunk size
[media] lirc: silence some compile warnings
[media] hdpvr: use same polling interval as other OS
[media] ir-kbd-i2c: pass device code w/key in hauppauge case
[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap
[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map
[media] rc/keymaps: Rename Hauppauge table as rc-hauppauge
[media] rc-rc5-hauppauge-new: Fix Hauppauge Grey mapping
[media] rc-rc5-hauppauge-new: Add support for the old Black RC
[media] rc-rc5-hauppauge-new: Add the old control to the table
[media] rc-winfast: Fix the keycode tables
[media] a800: Fix a few wrong IR key assignments
[media] opera1: Use multimedia keys instead of an app-specific mapping
[media] dw2102: Use multimedia keys instead of an app-specific mapping
...
Fix up trivial conflicts (remove/modify and some real conflicts) in:
arch/arm/mach-omap2/devices.c
drivers/staging/Kconfig
drivers/staging/Makefile
drivers/staging/dabusb/dabusb.c
drivers/staging/dabusb/dabusb.h
drivers/staging/easycap/easycap_ioctl.c
drivers/staging/usbvideo/usbvideo.c
drivers/staging/usbvideo/vicam.c
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>
