Eventually, I hope that I got most of Phil's and Stephen's remarks into this
patch. Patch is against the current CVS status (as of 2008-10-10).
Changes are mostly editorial, as suggested by Phil, plus a few constant
definitions and minor adjustments in the processing flow.
Added missing timeout/buffer full check detected by Stephen.
For details (relative to my previous patch) see following messages;
For details about the IR learning API, see attachment.
This patchset has been build and tested with a Harmony 785, on the
following platforms:
- LINUX (Mandriva Kernel 2.6.26.3-custom/gcc-4.3.2)
- Windows XP Home SP3 / Visual C++ Express 2008
Patchset description:
=====================
This patchset consists of two parts:
1/2 : changes to files in libconcord
2/2 : changes to concordance
== TODO ==
Functional:
- There are still a few functions in remote.cpp that expose
HID return values, which should return some LC_ERROR instead.
- Thinking about reasonable progress callbacks for LearnIR
(which will mean another change in the libconcord interface).
- Still no progress with PERL stuff.
- Still some tester for Mac needed.
Editorial:
- There's still lots of single-line blocks in both libconcord and
concordance that would need some braces, like:
if (foo)
printf("bar");
- We should also have some LC_OK or LC_SUCCESS (= 0), instead of returning
and checking against 0 all over the code.
- Checking return codes of functions against LC_OK:
if (try_something(data) != LC_OK) {...)
should IMHO also replace the frequent:
if (try_something(data)) { /* failed */...'
to make the code more readable.
I started to fix some of those, but didn't want to put too much into this
patch.
Andreas
Change of libconcord API for IR codes learning
==============================================
This patch changes the part of the libconcord API releated to learning IR
signals. The main goals of the new API are:
a) allow to process LearnIR.EZTut files containing more than one key to learn
(several keys selected in the web interface)
b) allow to inject IR signals from other sources, e.g. RC5 or NEC codes or
Philips Pronto Hex format.
Also included are some minor, mostly editorial, changes to fix warnings
reported/marked by MS Visual C++ 2008 and the kdevelop editor
(see detailed descriptions for parts 1 and 2)
API change:
===========
The new learning API consists of four functions, which implement distinct
processing steps of the received data. Splitting the processing allows the
application to process (i.e. to display or replace) the intermediate data.
The functions have to be called in the following order:
1) int get_key_names(uint8_t *data, uint32_t size,
char ***key_names, uint32_t *key_names_length);
To be called once in the beginning to return in key_names the key names and in
key_names_length the number of key names found in the buffer *data, i.e. the
contents of the received LearnIR.EZTut file.
Note that in post_new_code below, Logitech will only accept keynames already
present in the database or user-defined via 'Learn new Key' web page for the
current device, so it is essential to read the key names to be learned first.
For each key name, repeat the following:
2) int learn_from_remote(uint32_t *carrier_clock,
uint32_t **ir_signal, uint32_t *ir_signal_length);
Returns in carrier clock, ir_signal and ir_signal_length the IR code learned
from another remote control via Harmony IR receiver.
carrier_clock : in Hz, usually ~36000..40000
*ir_signal : IR mark/space durations (alternating) in microsconds
ir_signal_length : total number of mark and space durations in ir_signal.
ir_signal will start with a mark and end with a space
duration, so ir_signal_length will always be even.
The function will stop learning when the IR signal is interrutped for longer
than 0.5 sec.
It will return with LC_ERROR_READ if no IR signal at all is received
within 5 sec.
It will return LC_ERROR_IR_OVERFLOW if the received IR signal lasts
longer than 5 sec or has filled the available buffer space.
Note: An application may also provide the IR code in this format from
some other source. In this case, it is apparently not needed to call
learn_from_remote.
3) int encode_for_posting(uint32_t carrier_clock,
uint32_t *ir_signal, uint32_t ir_signal_length,
char **encoded_signal);
Returns in *encoded_signal as a string the IR code specified by carrier_clock,
ir_signal and ir_signal_length encoded to Logitech posting string format.
Note: an application may allow to display and enter IR codes in this format,
which would provide another format to exchange learned IR codes.
4) int post_new_code(uint8_t *data, uint32_t size,
char *key_name, char *encoded_signal);
Post encoded IR-code for key_name and using additional information from
received XML *data to Logitech.
All functions return 0 in case of success, or some error code (>0, defined in
libconcord.h) in case of an error.
In case of an error, output parameter values should not be used.
Functions 1)..3) allocate memory for the returned data, which should be freed
again after use by one of the following functions:
---------------------
void delete_key_names(char **key_names, uint32_t key_names_length);
void delete_ir_signal(uint32_t *ir_signal);
void delete_encoded_signal(char *encoded_signal);
-------------------------------------------------------------------------
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
