Hi Devin, Andy, On Wed, Oct 11, 2017 at 10:25:34PM -0400, Devin Heitmueller wrote: > Hi Andy, > > > 5. Rx and IR Learn both use the same external hardware. Not > > coordinating Rx with Learn mode in the same driver, will prevent Learn > > operation from working. That is, if Learn mode is ever implemented. > > (Once upon a time, I was planning on doing that. But I have no time > > for that anymore.) > > There's not really any infrastructure in Linux that maps to the > Zilog's "learning mode" functionality. Usually I would just tell > users to do the learning under Windows and send me the resulting .ini > file (which we could then add to the database). > > I had planned on getting rid of the database entirely and just > converting an MCE compatible pulse train to the blasting format > required by the Zilog firmware (using the awesome work you sent me > privately), but the fact of the matter is that nobody cares and MCEUSB > devices are $20 online. I wouldn't mind working on that, if I had the blasting format. :) Note that you can have IR Rx and Tx on a gpio port, so it can get even cheaper than $20. The hauppauge solution with a z8 microcontroller with it's non-obvious firmware and i2c format seem a bit ludricous. > > I'm glad someone remembers all this stuff. I'm assuming you had more > > pain with this than I ever did. > > This would be a safe assumption. I probably put about a month's worth > of engineering into driver work for the Zilog, which seems > extraordinary given how simple something like an IR blaster/receiver > is supposed to be. I guess that's the fun of proving out a new > hardware design as opposed to just making something work under Linux > that is already known to work under Windows. > > > I never owned an HD-PVR. > > I'm sure I have a spare or two if you really want one (not that you > have the time to muck with such things nowadays). :-) > > The HD-PVR was a bit of a weird case compared to devices like ivtv and > cx18 because it was technically multi-master (I2C commands came both > from the host and from the onboard SOC). Hence you could have weird > cases where one would block the other at unexpected times. I2C > commands to the Zilog would hold the bus which would delay the onboard > firmware from issuing commands to the video decoder (fun timing > issues). There was also some weird edge case I don't recall the > details of that prompted them to add an I2C gate in later board > revisions. Interesting. Thanks Sean
