Am 10.12.2012 21:48, schrieb Antti Palosaari: > 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. > Many thanks. So the problem is, that we have only a single RC_TYPE for all 3 protocol variants and need a method to distinguish between them, right ? Regards, Frank > > regards > Antti > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
