[pvrusb2] Problems with IR receiver (latest hardware version, latest driver, 2.6.20 kernel)

[Mike Isely]

On Sat, 5 May 2007, David Gatwood wrote:

>  On Friday, May 04, 2007, < rja at firkraag.rogera.net > wrote:
> 
> >If you mean the WinTV-PVR-USB2 MCE-Kit, then here are a couple of posts about
> >how to setup the USB SMK eHome beanbag IR transceiver with the
> >lirc_mceusb2 driver.
> >
> >http://www.isely.net/pipermail/pvrusb2/2006-February/000505.html
> >
> >and about using the transceiver as an IR Blaster to transmit IR signals:
> >
> >http://www.isely.net/pipermail/pvrusb2/2006-December/001198.html
> 
> No, I don't mean the MCE kit.  Sorry for the confusion .  The current
> version of the PVR-USB2 (models shipped after about February
> of this year or so) has an 1/8" mini jack for an external IR blaster.
> The mceusb driver doesn't match against anything when I load it.

You're not causing any confusion.  What's confusing here is that 
Hauppauge has effectively released a new model variant without actually 
changing any model-identifying info.  A year ago they didn't change the 
packaging at all but at least the USB ID changed.  Now they didn't even 
change the USB ID :-( (However unlike before, this time the hardware is 
a lot more similar.)

I'm unfamiliar with the "MCE kit", but reading between the lines here 
I'm guessing that the "MCE kit" was a PVR USB2 device paired with a 
separate outboard IR blaster.  Their "new" device here eliminates the 
outboard IR blaster because the device itself now has the IR blaster 
functionality built in (effectively a cost reduction).  The way to tell 
you have the new device is by the presence of the 1/8" jack on the 
front.


> 
> I'm not sure what I changed, but with the very latest (20070428a) driver
> and the latest build of lirc (0.8.2pre2, which provides the latest lirc_i2c
> driver version) receive is working, provided that I set the thing to point
> to /dev/lirc1 (the real hardware, as opposed to the faked one that the
> pvrusb2 driver creates).  Transmit, however, is still dead.

Actually, I'm very glad to hear this.  You just verified that LIRC knows 
how to handle the new IR receiver hardware in the device.  
Congratulations.  I believe the same I2C chip is doing both IR receive 
and transmit now, and thus the IR receive function is implemented 
differently now which is why the newer LIRC driver is needed.


> 
> Lirc is showing two i2c busses:
> 
> [   55.718165] lirc_i2c: chip found @ 0x18 (Hauppauge IR)
> [   55.722290] lirc_dev: lirc_register_plugin: sample_rate: 10
> [   55.727542] lirc_i2c: probe 0x71 @ pvrusb2_a: yes
> [   55.728791] lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
> [   55.733428] lirc_dev: lirc_register_plugin: sample_rate: 10
> [   55.738656] lirc_i2c: probe 0x4b @ pvrusb2_a: no
> [   55.739275] lirc_i2c: probe 0x64 @ pvrusb2_a: no
> [   55.739776] lirc_i2c: probe 0x30 @ pvrusb2_a: no
> [   55.740398] lirc_i2c: probe 0x6b @ pvrusb2_a: no
> 
> It looks like the first one is the faked one from the driver and the second
> one is a real chip on an i2c bus.  If I use the "ir_mode=0" flag to disable
> the fake IR bus, I only see the second one.  So it looks like I need to
> dig for info about the PVR150 IR transmitter to make this one work.

Yes, I think your conclusion is exactly correct.


> Any ideas?

This makes sense.  Allow me to explain...

Way back in the "day", back when the only model was the 29xxx device, 
the IR receiver was a separate I2C chip.  The pvrusb2 driver handled 
this by, well, completely ignoring it.  This worked out fine because the 
LIRC driver would scan the I2C bus inside the PVR USB2 device (because 
the pvrusb2 driver makes all internal I2C devices visible to the I2C 
subsystem in the Linux kernel), then it would spot the IR chip, and 
handle it on its own.

Then when the 24xxx devices appeared, Hauppauge cost-reduced the device 
by getting rid of the dedicated I2C IR receiver chip, replacing it (I'm 
guessing) with a bunch of FPGA logic and some new FX2 microcontroller 
commands.  Unfortunately this made the IR function no longer visible on 
the I2C bus which caused a problem for LIRC or anything else trying to 
do IR.  There wasn't any real direct way I could export those FX2 
commands out and I didn't want to get into the business of providing my 
own IR decoding.  So what I did instead was to create that "fake" IR 
receiver.  The pvrusb2 driver sees attempts to communicate with the I2C 
address where the 29xxx IR receiver would have been and it intercepts 
those requests, fulfulling them with corresponding FX2 microcontroller 
commands.  Thus we get a virtual IR receiver.  The net effect is that 
the 24xxx devices behaved exactly the same as the 29xxx devices for 
purposes of IR.  And everyone was happy :-)

Now along comes this latest 24xxx "variant".  This device has changed 
the IR picture again.  We're back to a dedicated I2C chip again, only 
now it's a different part, at a different I2C address, and it can 
transmit now too.  Because the pvrusb2 driver doesn't (yet) know about 
this, it is happily still trying to emulate 29xxx style IR using an FX2 
command that probably isn't there any longer.  Meanwhile, the "new" IR 
chip works fine.  So now LIRC is seeing two IR receivers on this device.

The short term way to deal with this is to use the new ir_mode module 
option to kill off the faked IR receiver.  Think multiple PVR USB2 
devices was the only reason I just did that option? :-)  Longer term I 
need to modify the pvrusb2 driver to figure out that it is talking to 
this newer device and to shut off the fake IR receiver on its own.  I 
have some ideas on how to do this, but I just haven't done it yet.  
(And really, this is an almost completely benign problem so I haven't 
worried about it much either.)

The real, final, solution is that LIRC (or whatever other outboard 
software) should operate the internal IR chip as we've been doing all 
along and the pvrusb2 driver should not have to care.  So long as LIRC 
can handle the new part then we're golden.  And you just confirmed the 
receive-half of that question for everyone :-)

I can't suggest much to deal with the transmit side, except to observe 
that from the pvrusb2 driver point of view, it's passing the I2C traffic 
correctly so whatever issues remain should just be LIRC related.  If / 
when you find the solution please post it here and I'll update the 
driver docs to match.

Hope that helps.

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