Em Tue, 11 Dec 2012 21:51:34 +0100 Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> escreveu: > 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 Actually, on both above, AFAIKT, instead of "key code", the last 8 bits are called as "command code" at the specs. > > > > 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. On all 32-bits NEC IR's I tested, this is mapped as: address code = AABBCC command code = DD Regards, Mauro -- 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
