Hello trid users,
some days ago i bought an flirc USB stick. This can receive infrared signals
and translate these to keyboard presses. With Flirc utility you can change the
the stored key codes and relation to received infrared signals. Such
configuration gave a specific 4 byte file name suffix. That is expressed
inside new TrID definition by line like:
<Ext>FCFG</Ext>
Luckily there exist a page about saving a configuration in Flirc user
guide. There the file structures are described by used header source. That is
expressed inside TrID definition by line like:
<RefURL>
https://flirc.gitbooks.io/flirc-instructions/content/ graphical-user-interface-guide/saving-a-configuration.html
</RefURL>
So i run trid utility on such examples. These samples are not recognized and
described as "Unknown!" (see appended trid-v-old.txt in output).
For comparison reason i also run the file format identification utility DROID
(See
https://sourceforge.net/projects/droid/). Here the samples are also not
recognized.
For comparison reason i also run file command (version 5.45) on such samples.
Here the samples are also not recognized and described as "data" (see
file-5.45.txt in output). The mime type therefor is application/octet-stream
triggered by binary nature of the samples (see appended file-i-5.45.txt in
output). Here no file name suffix is listed (see appended file-ext-5.45.txt in
output).
On Linux according to shared MIME-info database such samples are not
described.
So i run tridscan on samples to create new trid definition. Then i looked
inside, tried to understand and improve definition by looking in file command
patched according to source header files (see file.tmp in output).
The characteristics with version is still described by first XML
construct. This looks like:
<Bytes>EFBEADDE01000000</Bytes>
<Pos>0</Pos>
According to documentation this 4 byte magic read little endian hexadecimal as
DEADBEEF. At offset 4 major version number is stored as 2 byte little endian.
At offset 6 minor version number is stored as 2 byte little endian. So in my
examples version number is decimal 1.0. On the net i found few samples (like
raspberrytips_flirc_xbox_one_fb.fcfg tpdesign_flirc_config.fcfg) which are not
matched by created definition. These are samples dated about 2016. Apparently
there exist an older FCFG variant. So i mention this observed fact in remark
line.
Because DEADBEEF is probably not unique enough i keep version part and samples
are described by line like:
<FileType>flirc configuration (v1)</FileType>
The second XML looks like:
<Bytes>000000</Bytes>
<Pos>9</Pos>
According to documentation at offset 8 the number of used keys is stored as 4
byte little endian n. So i can create samples which contain only 1 key. Then
many constructs at higher offset vanish. Then it becomes visible per
ir_pattern_t 16 bytes are used. The whole file size is determinated by
multiplying n with 16 and adding 16 (size of header_t structure) and 12 (size
of settings_t structure). So i mention this observed fact in remark line. In
the documentation is written that the maximal number of stored keys is
160. Apparently this low limit is triggered by nature of USB-stick ( based on
embedded micro controller with limit memory): This also means the 3 upper
bytes in definition are never used and are nil. So this construct is always
true. So i keep it.
The third XML construct looks like:
<Bytes>FFFFFFFF0F00000000000000</Bytes>
<Pos>16</Pos>
According to documentation this is alg 0xffffffff, timing 0xf and general 0 of
settings_t structure if i interpret bytes correctly. I do not know what this
exactly means and if this can be changed. It is not characteristic but at the
moment i keep this.
The last construct looks like:
<Bytes>0000000000000000</Bytes>
<Pos>33</Pos>
At offset 28 the first ir_pattern_t structure start with 4 byte hash which is
different. At offset 32 time elapsed to next pulse in ms is stored as 4 byte
little endian. In my samples i got "low" values (like 0x440 x45 0x82). I
assume that in real samples this value is always in same range (3 upper bytes
are nil). At offset 36 pointer to next key to send is stored as 4 byte little
endian. This is at the moment not used. So in my samples i get always zero
values. At offset 40 boolean lp byte (if we should do a long press) is stored.
Assuming that other lp occur that last byte in construct vanish. So this will
become like:
<Bytes>00000000000000</Bytes>
<Pos>33</Pos>
Interesting are the last two bytes of ir_pattern_t structure to distinguish
the different FCFG. At offset 42 the first modifiers are stored as byte. So
for example value 3 means Left-CTRL+SHIFT. At offset 43 the key code is stored
as byte. So for example values 1e and 1f means keys 1 and 2. So i mention
observed facts in remark line.
With the new definitions my FCFG samples are now recognized (see appended
trid-v-new.txt in output). Older variant samples are still not described by
that definition. (see appended trid-v-new.txt in /output).
TrID definition, some samples and output are stored in archive fcfg_. I hope
that my definition can be used in future version of triddefs.
With best wishes
Jörg Jenderek
