RF signals (433 MHz and other carrier frequencies) do not use the IR typical modulation. Also there are a few IR protocols (Revox, Barco, Archer http://www.hifi-remote.com/forums/viewtopic.php?t=14186&start=40). These should be possible to send, at least if the used driver support it. Lirc presently assumes that remotes either without explicit frequency or with the frequency explicitly set to 0 in fact have the modulation frequency DEFAULT_FREQ. (Ok in the first case, not in the second.) It is implemented so that a remote without explict frequency get the frequency 0 when parsing (in config_file.c), and the driver turns the 0 into DEFAULT_FREQ (see eg. default.c).
I propose having lircd during parsing to set frequency = DEFAULT_FREQ if it is missing. That way explicitly non-modulated (freq = 0) remotes can co-exist with remotes without explicit frequency, the latter getting DEFAULT_FREQ. Possible implementation:
diff --git a/lib/config_file.c b/lib/config_file.c
index 835bd3d..e53f701 100644
--- a/lib/config_file.c
+++ b/lib/config_file.c
@@ -1026,10 +1026,12 @@ read_config_recursive(FILE f, const char name, int depth)
/ create first remote /
LOGPRINTF(2, "creating first remote");
rem = top_rem = s_malloc(sizeof(struct ir_remote));
+ rem->freq = DEFAULT_FREQ;
} else {
/ create new remote /
LOGPRINTF(2, "creating next remote");
rem = s_malloc(sizeof(struct ir_remote));
+ rem->freq = DEFAULT_FREQ;
ir_remotes_append(top_rem, rem);
}
} else if (mode == ID_codes) {
This still leaves a numer of driver turning 0 into DEFAULT_FREQ. That is actually not a big issue since they are (likely?) not able to handle non-modulated signals anyhow.
This basically looks sound to me, and this is the right time early in the 0.9.4 cycle to introduce it. Committed as [992583]
Related
Commit: [992583]
Thanx. The linked commit is something else though.
Oops... fixed in [1d1aff]
Related
Commit: [1d1aff]