On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a new
type RC_TYPE_NEC_NO_PARITY.
OTOH, introducing a new bitfield in struct rc_map might be usefull for
other flags, too, in the future...

It's probably also worth mentioning that in that mode the device
reports four bytes, not two.  I guess perhaps if parity is ignored it
reports the data in some other format?  You will probably have to do
some experimentation there.

Uh, current em28xx NEC implementation is locked to traditional 16 bit
NEC, where is hw checksum used.

Implementation should be changed to more general to support 24 and 32
bit NEC too. There is multiple drivers doing already that, for example
AF9015.


Hmm... are there and documents (, links, books, ...) where I can learn
more about all those RC protocols ?

Specification comes here:
NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:

1) 16bit NEC standard, 1 byte address code, 1 byte key code
full 4 byte code: AA BB CC DD
where:
AA = address code
BB = ~address code
CC = key code
DD = ~key code

checksum:
AA + BB = 0xff
CC + DD = 0xff

2) 24bit NEC extended, 2 byte address code, 1 byte key code
full 4 byte code: AA BB CC DD
where:
AA = address code (MSB)
BB = address code (LSB)
CC = key code
DD = ~key code

3) 32bit NEC full, 4 byte key code
full 4 byte code: AA BB CC DD
where:
AA =
BB =
CC =
DD =

I am not sure if there is separate parts for address and key code in case of 32bit NEC. See some existing remote keytables if there is any such table. It is very rare protocol. 1) and 2) are much more common.


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