[pvrusb2] Brand new HVR-1950 - no IR device!

[Mike Isely]

On Fri, 18 Jul 2008, Nat Tellin wrote:

> > What you *should* do instead, is deal with the zilog ir blaster / receiver.  This ic is located at i2c address 0x71, iirc.  If not 0x71, then 0x72 or something in that neighborhood.  (The zilog is actually addressable at multiple locations on the same unit, but that is a discussion beyond the scope of this thread)
> 
> This raises the question of why the lirc_i2c kernel module believes
> there to be an IR transmitter at 0x1a. And then, why is it not
> _always_ detected? Usually only by reloading the pvrusb2 module.
> 
> > In the end, the issue is that you are using the wrong LIRC configuration.  I can't blame you for this, since the pvrusb2 24xxx models did use the fx2-style IR located at pseudo i2c address 0x1a ( or was that 0x18 ? -- I forget ) , and that IR solution emulated the previous IR solution provided by the 29xxx units.
> 
> The address is specified by neither myself nor any of the lirc
> configuration files, and I've seen no means to override it (it
> wouldn't be quite as simple as specifying '0x71' even if so). The
> module makes this determination on its own through some means I'm not
> familiar with. I'll assume that it is probed for and thus unrelated to
> any hard-coded value or one from eeprom - correct me if I'm wrong.

The lirc kernel module for this tries to probe all the possible 
addresses.  It might be controllable via a module option but certainly 
end users are not expected to know this.  I2C "probes" are not 
exactly safe in nature.  The I2C spec never really was designed with 
the idea that devices could be probed for, but historically that is 
what happens in the Linux kernel's I2C subsystem.  (Yes, I know that 
situation has recently improved but I'm just trying to explain the 
history here.)

What Mike has pointed out is that the probe operation causes a fatal 
problem with the hardware.  What we have here is a situation where if 
you load the wrong Hauppauge IR driver, then the pvrusb2-driven hardware 
gets wedged.  Damnit.  I might be able to build a defense against this 
in the pvrusb2 driver, by detecting the probe attempt and filtering it 
out (I've had to do this already to protect the cx24840 from fatal 
probes by the msp3400 chip level driver).  But this approach is at best 
a horrible hack.


> 
> I'm not sure how the model designations work. I do know however that
> you mentioned 24 and 29xxx, which I've seen in firmware filenames
> (makes sense). However, as I didn't see it referenced I feel the need
> to point out that the firmware for my device contains 73xxx. Forgive
> me if that's irrelevant. Support seems to be very new for the HVR-1950
> - I'm inclined then to think that there may be a genuine issue hiding
> in here somewhere.

The original "PVR USB2" from Hauppauge didn't have a number in its name.  
But Hauppauge went through multiple major revisions of the device.  
There's a white sticker on the underside that identifies the module.  
The nomenclature "24xxx" refers to models with "24" in the leading 2 
digits.  The IR emulation is only for 24xxx devices and is safely 
disabled for all other device types.

Try Mike Krufky's recommended solution:

<quote>
What you actually need to do is configure this IR receiver device as
if it was a zilog commonly found on a Hauppauge PVR150.  I believe
that lirc has a predefined configuration for this, called
"lirc_pvr150" or something.
</quote>

I'd give large odds that this will work, and I'd love hear someone try 
this and save me the trouble of setting up LIRC on my test system (LIRC 
setup is a major PITA).

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8