[pvrusb2] PVR USB2 receiving IR keyboard codes

[Mike Isely]

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
                        |                             |