On 12/12/2012 11:34 PM, Frank Schäfer wrote:
Am 12.12.2012 22:25, schrieb Frank Schäfer:

...
Am 11.12.2012 21:59, schrieb Antti Palosaari:
See current af9015 driver as example how driver makes decision which
variant of NEC is used. You will need something similar. Read all 4
NEC bytes from the hardware and then use driver to make decision which
variant it is.
Yes, checking for inverted address and key code bytes would be a
possibility...

The problem here is of course, that we have to configure the device first.
So we need to know the protocol variant before getting any bytes from
the device...

No, you now don't see the point correctly. If you read 4 byte "full NEC" code from the hardware, you will not need to know which variant it is for configure hardware. 4 byte, full NEC, presents all the variants.

Think it like NEC code is always 4 byte long as lower layer. All NEC remotes sends 4 byte codes regardless which variant. In receiver side, after decoding there is also 4 byte always. Variants are done very upper layer after decoding.

Let me take some existing examples:
------------------
rc-trekstor.c:  { 0x0084, KEY_0 },
This is actually 1 byte NEC, which is device id == 0.
4 byte real code is: 00 ff 84 7b
------------------
rc-terratec-slim-2.c:   { 0x800d, KEY_0 },
This is normal, traditional, oldest, most common, 2 byte NEC.
4 byte real code is: 80 7f 0d f2
------------------
rc-terratec-slim.c:     { 0x02bd09, KEY_0 },
Extended NEC, quite common, 3 byte NEC.
4 byte real code is: 02 bd 09 f6
------------------
rc-tivo.c:      { 0xa10c8c03, KEY_NUMERIC_0 },
"full" NEC, 4 byte NEC.
Not very common, but coming slowly more popular.
4 byte real code is: a1 0c 8c 03


As you can see all NEC variants could be presented as 4 byte NEC. Even the "one byte NEC", which comes in that case (rc-trekstor.c) "00 ff 84 7b" as 4 byte real notation.


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to