[pvrusb2] Brand new HVR-1950 - no IR device!
isely at isely.net
Sat Jul 19 14:04:59 CDT 2008
On Thu, 17 Jul 2008, Michael Krufky wrote:
> I normally post my replies below the quote, but this isn't my list to
> police, so I will keep to the quoting style of the thread.
Let's try to not top-post if possible. It's just too confusing.
> Anyhow, Nat:
> You are attempting to utilize a device at i2c address 0x1a as an IR
> receiver, but this will not work for you, since the device at 0x1a is
> in fact NOT an IR receiver.
> The device at 0x1a is the atsc/qam demodulator. This particular ic
> has 16-bit registers, so when you address it using only 8 bits,
> results are unpredictable. This might be related to "[ 8780.549011]
> pvrusb2: Timed out control-write" message, which later rendered the
> device inoperable.
The "Timed out control-write" message is a sign of a fatal error. When
this happens, the driver has lost the ability to communicate with the
hardware. The scenario you describe is certainly a plausible
explanation for this, though it's unfortunate that any kind of
mis-addressed I2C transfer can fatally wedge the bus :-(
(Yes, Mike I understand that you probably know this already. Just
making it clear for others on this list.)
> The above has nothing to do with the issue at hand, but I mention it
> now so that it will be known for the future.
> 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)
> 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 24xxx device's IR behavior in hardware is unique, and not itself
supported by ANY LIRC combination. IR reception for 24xxx devices is
not done with an I2C device; it requires direct commands to the FX2
microcontroller, which is completely impossible for LIRC to do on its
That is why I implemented that "virtual" IR receiver in the pvrusb2
driver for 24xxx devices. In that case the driver will watch for
accesses to the relevant I2C address, and answer those accesses by
directly issuing FX2 commands. The emulation works perfectly.
The emulation is also only enabled when a 24xxx device is detected (the
controlling device attribute is "flag_has_hauppauge_custom_ir" in
pvrusb2-devattr.c which is only set for 24xxx devices). So for an
HVR-1950, this is a complete red herring. There ARE cases where the
emulation can cause confusion, but it's only for situations where you
are using a later 24xxx model with a built-in IR blaster. (In that case
Hauppauge changed the IR receiver to a different I2C device but since
they didn't change the USB ID of the device, the driver right now can't
detect the difference and so the emulation is still enabled, though in
this case benign.)
> 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.
Can someone on the list confirm that this works?
It's unfortunate that you have to select an option in LIRC that on the
surface sounds like it has nothing to do with this device :-(
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2