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: do you really think the driver should parse the whole rc map and check all scancodes to find out which sub-protocol is used ? > A 24-bits NEC table: > # table pixelview_002t, type: NEC > 0x866b13 KEY_MUTE > 0x866b12 KEY_POWER2 > ... > > A 32-bits NEC table: > # table tivo, type: NEC > 0xa10c900f KEY_MEDIA > 0xa10c0807 KEY_POWER2 > ... > > If you see there, there's no way for the Kernel to handle it wrong, as > there's an implicit rule when dealing with "extended NEC" protocols: > > Being the IR code being given by: AA BB CC DD > > 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 ! > 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 ! 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. Regards, Frank -- 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
