I just used the IR learning feature in congruity/libconcord to learn the "home" button of the original Roku Netflix player, and the Harmony website recognized the signal as a pre-existing key it knew about. So, the whole chain works!
Some feedback on error handling in the libconcord API: learn_from_remote() simply returns the result code from rmt->LearnIR unchanged. LearnIR() returns different "kinds" of error codes, depending on what error occurred. Sometimes, error codes from HID_(Read|Write)Report are returned directly, and sometimes, LC_* are returned. This makes it difficult for a client application to correctly interpret what went wrong. In particular, if the user never presses the button on the original remote, HID_ReadReport fails, and ends up returning error code -110 (on my system at least). Since this is non-zero, congruity treats this as an error. I can't special-case this error code, because there's no defined LC_* code to mean "timeout"; the -110 error code is unlikely to be portable (and I have no idea if it's specific to this case either). Can LearnIR() be modified to: a) Always return LC_* error codes. and b) On timeout, either: 1) Return a new LC_* error code for this specific reason or 2) Return "OK", and an empty array of learned data This will allow congruity to detect the timeout situation, and allow the user to retry the learning process. Other kinds of error would still be fatal. Right now, the error is treated as fatal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
