On 28/03/14 00:38, David Härdeman wrote:
Hi Malcolm,
Hi David
I'm trying to make sure that the extended NEC parsing is consistent
across drivers and I have a question regarding
drivers/media/usb/dvb-usb-v2/lmedm04.c
In commit 616a4b83 you changed the scancode from something like this:
ibuf[2] << 24 | ibuf[3] << 16 | ibuf[4] << 8 | ibuf[5]
into:
if ((ibuf[4] + ibuf[5]) == 0xff) {
key = ibuf[5];
key += (ibuf[3] > 0)
? (ibuf[3] ^ 0xff) << 8 : 0;
key += (ibuf[2] ^ 0xff) << 16;
which can be written as:
(ibuf[2] ^ 0xff) << 16 |
(ibuf[3] > 0) ? (ibuf[3] ^ 0xff) << 8 : 0 |
ibuf[5]
At the same time the keymap was changed from (one example from each
type):
0xef12ba45 = KEY_0
0xff40ea15 = KEY_0
0xff00e31c = KEY_0
These original key maps need to restored for 32 bit.
into:
0x10ed45 = KEY_0 (0x10ed = ~0xef12; 0x45 = ~0xba)
0xbf15 = KEY_0 (0xbf = 0x00bf = ~0xff40; 0x15 = ~0xea)
0x1c = KEY_0 (0x1c = 0x001c; this is a NEC16 coding?)
Bits 8~23 are inverted on the key map because they are shifted >> 8.
Bits 8~15 are removed from the scan code.
I am assuming (given the ^ 0xff) that the hardware sends inverted bytes?
And that the reason ibuf[5] does not need ^ 0xff is that it already is
the inverted command (i.e. ibuf[5] == ~ibuf[4]).
To put it differently:
ibuf[2] = ~addr = not_addr;
ibuf[3] = ~not_addr = addr;
ibuf[4] = ~cmd = not_cmd;
ibuf[5] = ~not_cmd = cmd;
And the scancode can then be understood as:
addr << 16 | not_addr << 8 | cmd
Except for when addr = 0x00 in which case the scancode is simply NEC16:
0x00 << 8 | cmd
Is my interpretation correct?
No inverting.
At the time of the patch I couldn't get the 32 bit code to work
correctly on rc_core so it was assumed to be 24 bit.
I have tested the patch series...
Is there a patch missing? I get build error from ati_remote.c and
imon.c
error: too few arguments to function 'rc_g_keycode_from_table'
Anyway, I removed the errors.
Just needs the inverting removed and the original 32 bit key maps to work.
Regards
Malcolm
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
