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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
