[pvrusb2] pvr-usb2 24xxx hauppauge remote with lirc and mythbuntu

[Mike Isely]

On Wed, 5 Dec 2007, blue c wrote:

> First,
> 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
> r,cx25840,pvrusb2,tveeprom,nvidia

  [...]

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 
found here:

http://www.isely.net/pvrusb2/usage.html#Logging

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

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