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 | | _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
