[pvrusb2] PVR USB2 receiving IR keyboard codes
Mike Isely
isely at isely.net
Sun Apr 8 21:00:30 CDT 2007
On Sun, 8 Apr 2007, Rafi Rubin wrote:
> The in kernel driver doesn't have working ir reception.
If the in-kernel driver doesn't have working IR reception, then that's
news to me. It should be working.
>
> You could identify which signals are overlapping and pull them from
> /etc/lircd.conf
>
> Or just assign them bogus key names.
>
To address the more general issue raised by Rod...
The pvrusb2 driver does not by itself handle IR reception. What it does
do however is make accessible a chip inside the device which does IR
reception. That chip is accessed via I2C bus transactions; the bus is
entirely inside the PVR USB2 device but the pvrusb2 driver implements an
I2C bus controller callable from within the Linux kernel thus any piece
of software in the kernel can access that controller to communicate with
I2C-connected chips within the device. IR reception is implemented for
pvrusb2 by loading of a separate kernel module which knows how to
operate the IR receiver chip. Such a module will operate the chip by
proxy through the I2C bus controller in the pvrusb2 driver. Said
another way, the pvrusb2 driver does not "do" IR, but it is an "enabler"
for another piece of software which will handle the IR reception.
So how well IR receptions works or doesn't work really depends on what
else (i.e. which IR chip level drivers) you've loaded in the kernel for
handling IR.
There are two possible such drivers I know of. One is the Hauppauge I2C
IR driver that is part of the lirc package. The other is a kernel
module that's part of V4L itself. The lirc implementation sends IR
events to an external daemon and what happens after that point depends
on how you have the daemon configured (i.e. go read the lirc docs).
The V4L resident driver implements a Linux input device so if it is
loaded it will translate IR events into keypresses and send them out to
userspace via a /dev/input/ device node.
So to control what happens here, you need to control which of these
kernel modules get loaded and attached to the pvrusb2 driver. It sounds
to me like Rod's issue is that ir-kbd-i2c (the V4L IR driver) is loaded
- try unloading it.
Much of this information is already described here:
http://www.isely.net/pvrusb2/usage.html#IR_handling
I actually lied a little bit above: the pvrusb2 driver in one specific
case will do something directly related to IR. If you're running a
24xxx PVR USB2 device, its IR hardware is completely different that what
is expected by lirc or ir-kbd-i2c and so rather than requiring different
IR drivers in that case the pvrusb2 driver will create a "virtual" I2C
device on its bus that acts like the IR receiver in the 29xxx device
(and many other Hauppauge devices). That "virtual" device will
translate attempts to manipulate it into calls to the hardware that
manipulate the real IR receiver, thus lirc and ir-kbd-i2c see exactly
the same "hardware" regardless of model type.
Another really low-tech solution is possible for Rod's situation - if
for some reason you can shut off or otherwise control the IR driver in
the kernel - put a piece of opaque tape over the front of the PVR USB2
device where the IR port exists :-)
>
> While we're on the topic, is it possible to make the pvrusb2 catch
> arbitrary ir signals, say those from other remotes?
What the pvrusb2 driver does here is not relevant. This ability is part
of lirc. Install lirc and you should be able to get multiple IR remotes
to work concurrently with the PVR USB2 hardware. I've never tried it,
but I would guess that about anything which is supported by lirc should
work. I do not know if the same can be said for the v4l ir-kbd-i2c
module.
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| |
More information about the pvrusb2
mailing list