[pvrusb2] pvr-usb2 24xxx hauppauge remote with lirc and mythbuntu
isely at isely.net
Thu Dec 6 01:17:55 CST 2007
On Wed, 5 Dec 2007, blue c wrote:
> Thanks for putting this project together. It performs amazing.
> Basic tv/pvr was so simple I decided to try for remote control but no luck
> so far.
> Box label: model 941
> Unit Label: 24022 LF Rev E1A3 NTSC / NTSC-J
> Features: FM receiver, hauppauge remote, irblaster that connects to box via
> 2mm plug
OK, then this is the device with a different type of IR receiver.
You're probably getting had by the "virtual" IR receiver that the driver
is creating for you...
> only have lirc0 and it looks almost like this is the 'correct' one. To this
> novice it appears that i2c device is created but does not appear that lirc
> is communicating with it. Any pointers?
> dmesg | grep lirc
> [ 70.844000] lirc_dev: IR Remote Control driver registered, at major 61
> [ 72.036000] lirc_i2c: chip 0x10005 found @ 0x18 (Hauppauge IR)
> [ 72.036000] lirc_dev: lirc_register_plugin: sample_rate: 10
> lsmod | grep lirc
> lirc_i2c 11268 2
> lirc_dev 15860 1 lirc_i2c
> i2c_core 26112 11 cx88xx,ivtv,bttv,i2c_algo_bit,lirc_i2c,wm8775,tune
Yup, that's the virtual receiver. I mentioned this a while ago on this
mailing list, but it's worth reviewing again:
A long time ago, back when only the 29xxx model existed, there was an IR
receiver chip built into it. The pvrusb2 driver did not do anything to
operate or otherwise interact with it - however that was just fine
because there were other I2C client drivers that could attach to the
device's I2C bus (as made available by the pvrusb2 driver), detect the
IR receiver chip, and operate it. The original "Hauppauge" I2C IR
receiver in lirc could do this and that's the method I've recommended
for handling IR reception. You can also use the ir-kbd-i2c module in
v4l-dvb to drive this chip.
Then along came the Hauppauge 24xxx model. The "first version" of this
model did not have an IR blaster. In addition - in a cost reduction
mode - Hauppauge deleted the original dedicated I2C based IR receiver
chip and replaced it with a bunch of custom logic controlled directly by
the device's FX2 microcontroller. Once I understood this and managed to
reverse-engineer the FX2-hosted API for this, I implemented a "virtual"
IR receiver chip in the driver. This was a small piece of code which
hooked into the pvrusb2 driver's I2C adapter such that it could
intercept I2C transfers destined for what would have been the real I2C
IR receiver chip. The intercepted transactions were then translated
into FX2 commands and the result handed back to whomever issued the I2C
transfer. The net effect of this is that IR reception on these 24xxx
devices looked exactly like the older 29xxx device IR implementation.
This then allowed the previous solution (e.g. use LIRC or ir-kbd-i2c) to
continue working unchanged.
Then Hauppauge respun the 24xxx model. They did not change the USB ID.
But they did change the IR again. This newer model has an IR blaster
built into it - and the chip being used for this also has an IR receiver
in it. With this change back to a dedicated I2C based IR receiver chip,
they got rid of the FX2 hosted IR receiver. Unfortunately (and as one
might guess) the new IR receiver is completely incompatible with what
had been done before.
Compounding this difficulty is that since the USB ID of this device is
the same as the "previous" 24xxx model, the pvrusb2 driver currently
cannot tell it apart from the older device. Because of this, the
pvrusb2 driver still enables the virtual IR receiver logic, thus you
will now see 2 IR receivers - the real one in the device, and the
virtual (fake) one that won't work. (I have an idea to fix this such
that the driver can detect this situation and not enable the virtual IR
receiver, but I haven't had the time yet to implement it and honestly
it's not a showstopper problem.)
Solving this involves two things. First, you have to ignore the fake
device or just disable it. There's a module option you can use to
disable the fake IR receiver. Information on all module options can be
The option you want is ir_mode - I leave it as a homework assignment for
you to read how that works :-) (However you don't actually HAVE to
disable it; you can also just choose to ignore the fake receiver. Oh,
and if you are using the in-kernel driver, this ability to disable the
receiver was added roughly last April so it probably won't be present
for kernels older than roughly 2.6.22.)
The other thing you need to do is attach an I2C client driver that knows
how to run the newer IR receiver in the device. I personally have not
tried to figure this out - however others have figured it out. And my
understanding is that the latest version of LIRC contains a module that
can work with the later IR receiver. I don't remember that module's
name off the top of my head, but I imagine it should be obvious by
inspection when you configure LIRC.
I see you also attempted to post your system log to this list - the post
got redirected into the moderation bin because it was too large. I'm
going to reject that posting; there's no need to let it through since I
think it's pretty well understood what is really going on here.
| 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