Well, thanks for your precious time... Seems like all this 'Harmony vs. Concordance', 'LINUX vs. Windows' and 'ANSI vs. C99' stuff has settled enough to try and merge my other two patches, so here just a few short notes to your comments:
On Monday 31 March 2008, Phil Dibowitz wrote: > OK, I spent some time today going through the IR code. I committed some > changes that aside from style and cleanup, adds some comments. > > A FEW of those comments are best-guesses of what's happening since I've > never really dug into how IR details and thus am not 100% sure I understand > the details. I'd REALLY like someone to go read through my comments and see > if they agree with my assessment of the code. I will have a look (NET I have finished the other patches). There still seems to be some more USB and network snooping left before I have reached deeper understanding of Logitech's IR code learning stuff myself - so far I have mainly built upon and adapted the existing code. > > * - TODO: > > * 1. Check if set_key_name before post_current_ir_code will > > * create a new entry or replace the name in the database. > > Why do you want to expose a set_key_name() API when it seems like the > canonical source for that data is in fact the HEX file? Depending on how the database reacts on POSTing a new key name that is not yet in the database (didn't check that yet), it may allow to add new keys without that tedious iteration through the Logitech pages, by just setting the new key name, learning and posting the corresponding IR sequence, re-using the original Hex file (except for the key name). > > * 2. Find out how to learn multiple keys > You mean learn a key that can do a sequence of keys? As far as I know, you > don't learn a sequence, you learn individual keys, and then sequences are > put together by "activities" on the website. Nope - my point was the procedure where you check multiple keys for learning in the key list, and the software asks you for all of them in one batch. I snopped such a session, but did not find time to check the details of the files sent by Logitech and back. > > * 3. Find out if/how unmodulated IR is handled by the Harmony > > * (carrier_frequency=0 ?) > > OK, my ignorance of IR is showing here, but can you expand upon this a bit? > Would this be IR that doesn't do on-off pulses and instead a solid burst? > or...? or. Unmodulated means that there is no carrier, i.e. the code is not a sequence of carrier bursts and breaks, but just the LED turning ON for some time as HI signal and OFF for some other time as LO signal. Some remotes seem to work this way - just have to find one to see what the Harmony sets as carrier frequency in this case. > > * 4. Does learn_ir_from_remote need prep_learn_ir_command, i.e. > > * any information from the received hex file required? > I don't think so, you could call prep_learn_ir_command() any time before > the post_ir_command() > > int set_key_name(char *key_name); > Again, I'm not clear this is necessary. see above. Either keep it for the first draft, dismissing it in case it's of no use, or leave it out now, to add later in case it should prove to work as intended? > > int get_pulse_list(uint8_t **pulse_list, uint32_t *number_of_pulses); > Probably the later... OK, would have some symmetry to set_pulse_list, and list and length belong together anyway. Probably even bundle them in a struct? That's all on this topic for now, back to the other patches waiting.. Andreas ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
