[pvrusb2] My HVR-1950 IR Remote does work

[Mike Isely]

On Sat, 30 May 2009, roccomoretti wrote:

> Roger wrote:
> 
> > Are people sure they're really meaning to state, "The HVR-1950 IR
> > Blaster doesn't work yet with lirc?"

My understanding is that (until your report) NOBODY has been able to get 
the IR to work AT ALL for the HVR-1950.

> 
> Probably. As best as I can tell (I'm no expert), the IR Blaster is not
> controlled by the CPU, but rather by a separate Zilog processor inside the
> HVR-1950. This means that you can't send any old codes to the blaster, you
> have to use a set program that's encoded in the firmware, and vanilla lirc
> isn't set up to handle this. There's a guy who's made a kernel module to
> control the blaster on the PVR-150
> (http://www.blushingpenguin.com/mark/blog/?p=24), which is supposed to have a
> similar IR control system to the HVR-1950, but I get an error message when I
> try to use it and am unaware of anyone who has got it working with the
> HVR-1950.

It's a known fact that the pvrusb2 driver is reporting an I2C ID that 
really isn't right (I2C_HW_B_BT848).  It's possible that this is the 
reason why the HVR-1950's IR won't work while the IR-identical PVR-150 
will.

The reason for this difference is due to history.  When I first started 
working on this driver (Jan 2005) it was completely out-of-tree, meaning 
that I didn't really have any ability to add a new ID since that would 
require a change to in-tree code.  So I left in place *something* that 
at least had a chance to work.  This situation dates back to the very 
very early days of my work on the driver, and frankly by the time the 
driver went in-tree I had long forgotten about this since after all it 
wasn't (at that time) causing any pain.  It could be the cause now.

With that said it would be a simple matter to define a new ID and get it 
inserted into the appropriate kernel header.  But that introduces two 
complications.  First if it isn't the same as what the PVR-150 reports 
then the two are still "different", we really haven't immediately fixed 
anything, and the LIRC driver will probably have to have a corresponding 
change.  But even more significantly, these I2C ids are on the way out.  
The I2C maintainer is moving over to a different kind of binding model 
that allows client drivers (such as lirc) to find adapter drivers (such 
as the pvrusb2 driver).  There are some key changes here - and in fact I 
am pretty certain this is going to break LIRC's I2C support for a while 
unless the maintainers there are on the ball (I have no idea if they 
are).  But with those ids going away there isn't much point to introduce 
a new one for the pvrusb2 driver and I suspect that even if I tried it 
won't be accepted since this old mechanism is becoming obsolescent.

With all that said, if someone would like to examine what is being done 
in this regard for the PVR-150 and send me a patch for the pvrusb2 
driver, I'll happily include it at least for the standalone driver for 
now.

Then again if Roger is able to make this at least partially work then 
maybe everything I've said above is unneeded.


> 
> P.S. Silly question, but just to check - the HVR-1950 is the only IR sensing
> device on your system, right? Is there a chance that lirc is picking up the
> remote's signals on some other input?

Roger has another (29xxx I think) device nearby but he did tell me that 
he disconnected it once just to prove that the signals were not coming 
from it.

  -Mike


-- 

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