Em Fri, 14 Dec 2012 16:33:34 +0100 Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> escreveu: > Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab: > > Em Tue, 11 Dec 2012 22:59:06 +0200 > > Antti Palosaari <crope@xxxxxx> escreveu: > > > >> On 12/11/2012 10:51 PM, Frank Schäfer wrote: > >>> 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: > >>>>> 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 ? > > This is not actually needed, as it is very easy to distinguish them when > > doing the table lookups. Take a look at v4l-utils, at /utils/keytable/rc_keymaps: > > > > A 16-bits NEC table: > > # table kworld_315u, type: NEC > > 0x6143 KEY_POWER > > 0x6101 KEY_VIDEO > > ... > > So 0x6143 is not the same as 0x006143 and 0x00006143 ??? > > And even when assuming that 00 bytes are unused: I never seen that. > do you really think the > driver should parse the whole rc map and check all scancodes to find out > which sub-protocol is used ? Scancode search can use a b-tree (I think it currently does). In any case, the typical usage is that the IR table will match the IR device in usage. So, a not-found scancode just means that some error happened during the transmission. > > On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would > > be a 16-bit NEC. > > No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be > 16, 24 or 32bit ! Have you ever seen any remote using something like that??? The hole point of the IR address is to distinguish a given IR device from the others. The specs define specific addresses for VCR, TV Set, DVD, etc. So, no, if AA == ~BB it must be a 16 or 24 bits NEC protocol, as there's just 8 bits (or 16 bits) to differentiate the IR address for a given remote from other NEC IR addresses. > > On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be > > a 24-bit NEC. > > Right, if CC != ~DD it must be 32 bit. > > > So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or > 16 bit ! It is 16 bits, except if someone at the manufacturer is completely senseless, and explicitly wants to cause troubles to their customers by using an IR address and IR commands that could be produced by some other vendor's remotes. In any case, the RC core will still support such crappy device, as the IR keytable can have a mix of 16 bits/24 bits/32 bits NEC codes inside it. We do have some tables with multiple IR's inside. For example, the Hauppauge RC5 table contains keycodes for 3 different types of Hauppauge controls. The same happens to one NEC's terratec table, where we're storing there both the codes of different IR models. The rationale is that the same board may be sold with different remotes. > Anyway, first we have to GET the bytes from the hardware. That's our > current problem ! > And the hardware seems to need a different setup for reg 0x50 for the > different NEC sub protocols. > Which means that the we need to know the sub protocol BEFORE we get any > bytes from the device. No. All em28xx needs is to make sure that the NEC protocol will return the full 32 bits scancode. 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
