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>
Per Pieter Hoekstra:
I have a Antec Fusion with a iMON Lcd and I get the following error:
imon 6-1:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id
0x9e)
The driver is functional if I load it like this: (I do not use a remote for it)
modprobe imon display_type=1 (On Mythbuntu 10.04/2.6.32)
This device is a lcd-type with support for a MCE remote. Looking at
the source code, this device (0x9e) is the same as id 0x9f.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v2: copy of buffer data from userspace done inside this plugin/driver,
keeping the actual drivers minimal, and more flexible in what we can
deliver to them later on (they may be fed from within kernelspace later
on, by an in-kernel IR encoder).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v2: currently unused ioctls are included, but #if 0'd out
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
mchehab: merged with IR/mceusb: userspace buffer copy moved out of driver
Userspace buffer copy moved out of driver and into lirc bridge driver
[mchehab@redhat.com: merged the patch to avoid compilation errors with allyesconfig ]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I have pinnacle hardware now. None of this pinnacle-specific crap is at
all necessary (in fact, some of it needed to be removed to actually make
it work). The only thing unique about this device is that it often
transfers inbound data w/a header of 0x90, meaning 16 bytes of IR data
following it, so I had to make adjustments for that, and now its working
perfectly fine.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The first-gen mceusb device init code, while mostly functional, had a few
issues in it. This patch does the following:
1) removes use of magic numbers
2) eliminates mapping of memory from stack
3) makes debug spew translator functional
Additionally, this clean-up revealed that we cannot read the proper default
tx blaster bitmask from the device, we do actually have to initialize it
ourselves, which requires use of a somewhat gross list-based mask inversion
check.
This patch also removes the entirely unnecessary use of struct ir_input_state.
Also supersedes two earlier patches that also touched on first-gen
cleanup, but were partially botched. This one actually compiles, works,
etc., I swear. ;)
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Was using input_unregister_device directly, instead of using
ir_input_unregister, which tears down a bunch of other things in
addition to eventually calling input_unregister_device.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Was using input_unregister_device directly, instead of using
ir_input_unregister, which tears down a bunch of other things in
addition to eventually calling input_unregister_device.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix ir-nec-decoder build: it uses bitrev library code, so
select BITREVERSE in its Kconfig.
ir-nec-decoder.c:(.text+0x1a2517): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2526): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2530): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2539): undefined reference to `byte_rev_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
With this change, it is now possible to do something like:
su -c 'echo "none +rc-5 +nec" > /sys/class/rc/rc1/protocols'
This prevents the need of multiple opens, one for each protocol change,
and makes userspace application easier.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Writing "none" to /dev/class/rc/rc*/protocols will disable all protocols.
This allows an easier setup, from userspace, as userspace applications don't
need to disable protocol per protocol, before enabling a different set of
protocols.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While rc-5 and rc-6 protocols are generally abreviated as "rc5" and "rc6",
previous sysfs nodes uses rc-5 and rc-6 for the Philips protocols. This is
consistent with the protocol nomenclature given by the original Philips
spec: "Remote control system RC-5" (doc. Nr. 9398 706 23011).
Also, rc5 is the name of a widely known cryptography protocol.
So, the better is to keep referring to those protocols as "rc-5" and "rc-6".
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using "magic" sizes for protocol names, replace them by an
array, and use strlen().
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
This is a new driver for the Windows Media Center Edition/eHome
Infrared Remote transceiver devices. Its a port of the current
lirc_mceusb driver to ir-core, and currently lacks transmit support,
but will grow it back soon enough... This driver also differs from
lirc_mceusb in that it borrows heavily from a simplified IR buffer
decode routine found in Jon Smirl's earlier ir-mceusb port.
This driver has been tested on the original first-generation MCE IR
device with the MS vendor ID, as well as a current-generation device
with a Topseed vendor ID. Every receiver supported by lirc_mceusb
should work equally well. Testing was done primarily with RC6 MCE
remotes, but also briefly with a Hauppauge RC5 remote, and all works
as expected.
v2: fix call to ir_raw_event_handle so repeats work as they should.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is the RC6 keymap for the Windows Media Center Edition remotes
that come bundled with MCE/eHome Infrared Remote transceivers. Tested
with 3 different variants of the remote, but its possible there are
still some additional keys missing, but its simple enough to add them
in later...
This patch also adds an IR_TYPE_ALL convenience macro to make life
easier for receivers that support all IR protocols.
v2: fix an erroneous comment that referred to imon devices
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
On Fri, May 28, 2010 at 3:59 PM, Jarod Wilson <jarod@redhat.com> wrote:
> The mceusb driver I'm about to submit handles just about any raw IR you
> can throw at it. The ir-core loads up all protocol decoders, starting
> with NEC, then RC5, then RC6. RUN_DECODER() was trying them in the same
> order, and exiting if any of the decoders didn't like the data. The
> default mceusb remote talks RC6(6A). Well, the RC6 decoder never gets a
> chance to run unless you move the RC6 decoder to the front of the list.
>
> What I believe to be correct is to have RUN_DECODER keep trying all of
> the decoders, even when one triggers an error. I don't think the errors
> matter so much as it matters that at least one was successful -- i.e.,
> that _sumrc is > 0. The following works for me w/my mceusb driver and
> the default decoder ordering -- NEC and RC5 still fail, but RC6 still
> gets a crack at it, and successfully does its job.
>
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
>
> ---
> drivers/media/IR/ir-raw-event.c | 7 ++++---
>
> diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
> index ea68a3f..44162db 100644
> --- a/drivers/media/IR/ir-raw-event.c
> +++ b/drivers/media/IR/ir-raw-event.c
> @@ -36,14 +36,15 @@ static DEFINE_SPINLOCK(ir_raw_handler_lock);
> */
> #define RUN_DECODER(ops, ...) ({ \
> struct ir_raw_handler *_ir_raw_handler; \
> - int _sumrc = 0, _rc; \
> + int _sumrc = 0, _rc, _fail; \
> spin_lock(&ir_raw_handler_lock); \
> list_for_each_entry(_ir_raw_handler, &ir_raw_handler_list, list) { \
> if (_ir_raw_handler->ops) { \
> _rc = _ir_raw_handler->ops(__VA_ARGS__); \
> if (_rc < 0) \
> - break; \
> - _sumrc += _rc; \
> + _fail++; \
> + else \
> + _sumrc += _rc; \
Self-NAK. The only place we actually *care* about the retval from a
RUN_DECODER() call is in __ir_input_register(), and currently, its
looking for retval < 0, which is currently never possible. When we're
running the decoders, either they fail and return -EINVAL or they
succeed and return 0, and in the register case, we get either a
negative error (ex: -ENOMEM from rc6) or 0, so with the above, _sumrc
will *always* be 0 in the two cases I'm looking at. The third place
where RUN_DECODER gets called (decoder unregister) doesn't care about
the retval either. New patch below, including updated comments about
the macro.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It makes IR to work again for dm1105 and, possibly, others.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix ir-nec-decoder build: it uses bitrev library code, so
select BITREVERSE in its Kconfig.
ir-nec-decoder.c:(.text+0x1a2517): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2526): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2530): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2539): undefined reference to `byte_rev_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add auto-config support for iMON 2.4G LT RF device, based on
debug output from Giulio Amodeo in Red Hat bugzilla #572288.
Also flips the switch on only setting up the rf associate sysfs
attr only if we think we're looking at an RF device, vs. previously,
setting up the attr for all 0xffdc devices, so its possible (but a bit
unlikely) there's another iMON RF device we'll have to fix up.
Nb: should be applied after "IR/imon: clean up usage of bools", or there
will be a slight contextual mismatch.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was a mix of 0/1 and false/true. Pick one convention and stick
with it (I picked false/true).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix ir-nec-decoder build: it uses bitrev library code, so
select BITREVERSE in its Kconfig.
ir-nec-decoder.c:(.text+0x1a2517): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2526): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2530): undefined reference to `byte_rev_table'
ir-nec-decoder.c:(.text+0x1a2539): undefined reference to `byte_rev_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change adds support for one more remote control type for Avermedia
M135A (model RM-K6), shipped with Positivo machines.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change adds support for Avermedia M733A. The original version for
linux 2.6.31 was sent to me from Avermedia, original author is unknown.
I ported it to current kernels, expanded and fixed key code handling for
RM-K6 remote control, and added an additional pci id also supported.
[mchehab@redhat.com: make checkpatch.pl happier]
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Tue, May 04, 2010 at 06:06:41PM +0200, Dan Carpenter wrote:
> On Tue, May 04, 2010 at 10:03:18AM -0400, Jarod Wilson wrote:
> > @@ -1205,7 +1204,7 @@ static u32 imon_panel_key_lookup(u64 hw_code)
> > if (imon_panel_key_table[i].hw_code == (code | 0xffee))
> > break;
> >
> > - keycode = imon_panel_key_table[i % IMON_KEY_RELEASE_OFFSET].keycode;
> > + keycode = imon_panel_key_table[i].keycode;
> >
> > return keycode;
> > }
>
> There is still potentially a problem here because if we don't hit the
> break statement, then we're one past the end of the array.
D'oh. Okay, here's v2, should fix that buglet too.
This hack was used when the imon driver was using internal key lookup
routines, but became dead weight when the driver was converted to use
ir-core's key lookup routines. These bits simply didn't get removed,
drop 'em now.
Pointed out by Dan Carpenter.
v2: fix possible attempt to access beyond end of key table array,
also pointed out by Dan.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds a missing include linux/delay.h to prevent
build failures[1-5]
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If there is an error here we should unlock in the caller (which is
imon_init_intf1()). We can remove this stray unlock.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is a typo here. We meant to test "ir" instead of "props". The
"props" variable was tested 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 original condition is always false because ! has higher precedence
than == and neither 0 nor 1 is equal to IMON_DISPLAY_TYPE_VGA.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Simplified from version 1, in that hacks heisted from ati_remote2.c
aren't actually necessary, the real fix for too many repeats was
from setting too long a timer release value (200ms) on repeats in
mce mode -- this patch drops the release timeout to 33ms, matching
the input subsystem default input_dev->rep[REP_PERIOD].
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a follow-up to my prior patch implementing ir-core's
change_protocol functionality in the imon driver, which eliminates
a false warning when change_protocol is called without a specific
protocol selected yet (i.e., still IR_TYPE_UNKNOWN). It also removes
some extraneous blank lines getting spewn into dmesg.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Pulse-distance is not a protocol, it is a line coding (used by some protocols,
like NEC). Looking at the uses of IR_TYPE_PD, the real protocol seems to be
NEC in all cases (drivers/media/video/cx88/cx88-input.c is the only user).
So, remove IR_TYPE_PD while it is still easy to do so.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drop the imon driver's internal protocol definitions in favor of using
those provided by ir-core. Should make ir-keytable Just Work for
switching protocol on the fly on the imon devices that support both the
native imon remotes and mce remotes.
The imon-no-pad-stabilize pseudo-protocol was dropped as a protocol, and
converted to a separate modprobe option (which it probably should have
been in the first place). On the TODO list is to convert this to an as yet
unwritten protocol-specific options framework.
While the mce remotes obviously map to IR_TYPE_RC6, I've yet to look at
what the actual ir signals from the native imon remotes are, so for the
moment, imon native ir is mapped to IR_TYPE_OTHER. Nailing it down more
accurately is also on the TODO list.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix some confusing comments in drivers/media/IR/*
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/IR/ir-keytable.c would alloc a suitably sized keymap table
only to have it resized as it is populated with the initial keymap.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix a double initialization of the same spinlock in drivers/media/IR/rc-map.c.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
