[pvrusb2] My HVR-1950 IR Remote does work

[Roger]

On Sat, 2009-05-30 at 18:16 -0400, Michael Krufky wrote:
> On Sat, May 30, 2009 at 5:38 PM, Roger <rogerx at sdf.lonestar.org> wrote:
> > pvrusb2_b: i2c scan: found device @ 0x70
> > pvrusb2_b: i2c scan: found device @ 0x71
> > pvrusb2_b: i2c scan: found device @ 0x72
> > pvrusb2_b: i2c scan: found device @ 0x73
> 
> All four of these refer to the IR Receiver / Blaster.  This is a single device.
> 
> 
> The addresses that disappeared had nothing to do with the IR hardware
> -- I am interested, however, in why the ATSC/QAM demodulator's
> addresses didn't show up, although I have an idea what could have
> caused it.....
> 
> The i2c_scan module option is really meant as a debugging tool.  You
> shouldn't have i2c_scan enabled under normal operation.

I believe I've set my pvrusb2 module option for debug??  (This was
needed as I had an old faulty pvrusb2 device sometimes omitting to
detect the i2c address of the IR receiver and is invaluable to detect
when it hasn't been detected.)

> Some hardware with 16-bit registers will get confused when a driver
> scans the i2c bus.  Sometimes the driver will issue an 8-bit read to a
> 16 bit register, and will misinterpret the second 8 bits as a valid
> read from the next i2c address.

Possible reason the hvr-1950 is failing to initialize properly then.
I'll disable as I prefer the newer hvr-1950 over the older pvrusb2
device.


> If the DVB frontend was successfully registered anyway, then this is a
> moot point, entirely.  There may be a race condition that prevented
> the i2c addresses from showing up in the scan, but if the DVB frontend
> was successfully initialized, then there really is no issue.

Yea. It's wicked... as to the reason I'm holding-off and waiting to see
how things further operate. ;-)

> 
> So, what actually matters (with respect to the ATSC/QAM demod) is
> whether or not you see a line in dmesg like this:
> 
> DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)...

The scenario you are describing is playing-out here is on-the-ball.  The
first initialization failed to emit the above "Samsung" within dmesg
while the second initialization does. 

> 
> Back to the original point, the IR receiver and IR blaster
> functionality are both provided by the same chip.  The IR receiver is
> built into the HVR1950, and you dont need to plug in any cables to use
> it.  The IR Blaster, however, requires the blaster cable to be plugged
> in and aimed directly at the set top box (or whatever) mounted at
> close proximity.
> 
> As far as lirc goes, I recommend to use the latest version.  The IR
> blaster support for the pvr150 is exactly the same as what would be
> required for the HVR-1950 -- the same zilog chip is used in both
> designs.  There was a plan to rename lirc_pvr150 to lirc_zilog , but
> I'm not sure what version of lirc has that change.  I have not tested
> this myself, but I have heard from others that it works for both the
> HVR-1950 and the HD-PVR.  (both use the same IR solution as the
> PVR150)
> 
> -Mike Krufky

<shrugs> I just built lirc with LIRC_DEVICES="hauppauge"
within /etc/make.conf so use flags for the gentoo package are "X
kernel_linux lirc_devices_hauppauge" and it works.  Probably just need
to remap the keys.

As far as the plugin ir blaster, does it just transmit, or does it also
receive?  (The mini jack plug as four contact points.)

-- 
Roger
http://rogerx.freeshell.org