On 12/14/2012 05:33 PM, Frank Schäfer wrote:
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari <cr...@iki.fi> 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.
I don't understand you. As to prove this possible, I made simple test.
Patch attached.
Tested with two devices, em2884 and em28174. Here are the results:
rc-anysee.c: { 0x0800, KEY_0 },
em28xx_rc: 81 08 f7 01 fe
em28xx_rc: 01 02 bd 00 ff
rc-terratec-slim.c: { 0x02bd09, KEY_0 },
for my eyes the results, output from the hardware, is just what we want.
I will not change my opinion until you prove I made some mistake and it
could not work. This is just similar what goes to af9015 and could be
implemented similarly in order to make it general NEC IR receiver.
RC-core stupid key binding with all the variants is another stupid issue
which should be fixed by converting all the key maps to 32bit format and
use only it. IMHO.
regards
Antti
--
http://palosaari.fi/
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 660bf80..d26c5f7 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -257,6 +257,8 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
*/
rc = dev->em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR,
msg, sizeof(msg));
+
+ pr_info("%s: %*ph\n", KBUILD_MODNAME, 5, &msg);
if (rc < 0)
return rc;
@@ -352,6 +354,8 @@ static int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 *rc_type)
struct em28xx *dev = ir->dev;
u8 ir_config = EM2874_IR_RC5;
+ *rc_type = RC_BIT_NEC;
+
/* Adjust xclk based o IR table for RC5/NEC tables */
if (*rc_type & RC_BIT_RC5) {
@@ -369,6 +373,8 @@ static int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 *rc_type)
em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
EM28XX_XCLK_IR_RC5_MODE);
+ ir_config = 0x01; // 32bit NEC
+
/* Setup the proper handler based on the chip */
switch (dev->chip_id) {
case CHIP_ID_EM2860:
