Re: [PATCH v2 0/9] rc: Add IR encode based wakeup filtering

["David Härdeman" <david@hardeman.nu>]

On Mon, Mar 17, 2014 at 10:34:25PM +0000, James Hogan wrote:
>It's ambiguous the other way too (which is probably a strong point against 
>having actual protocol bits for each NEC variant, since they only differ in 
>how the scancode is constructed). E.g. the Tivo keymap is 32-bit NEC, but has 
>extended NEC scancodes where the bytes of the command are complements (i.e. 
>the extended NEC command checksum passes). This makes it hard to filter on at 
>the scancode level (the drivers will probably get it right for the hardware 
>filters, but the software filter will likely get it wrong in those corner 
>cases since it knows nothing of NEC).
>
>There's multiple ways the NEC scancode formats could be improved 
>(incompatibly!) to reduce the problems, but none are perfect.
>
>E.g. one possibility is to scrap the NEC and extended NEC scancodes and just 
>use 32-bit NEC scancodes format throughout:

YES!

All the "knowledge" of "original" NEC (16 bit), "extended" NEC, etc that
have multiplied over both drivers and in various parts of rc-core is a
big mistake IMHO. The only sane way of handling NEC is to always treat
it as a 32 bit scancode (and only in cases where e.g. the hardware
returns or expects a 16 bit value should the scancode be converted
to/from the canonical 32 bit format). There is absolutely no advantages
in trying to parse or "understand" the NEC format unless it absolutely
cannot be avoided.

I haven't had the time to really review your patches in depth, but
whatever you do, please try to keep any knowledge of NEC 16/24/32 bit
distinction out of any functionality you add.

I had a suggested patch before which would also make the keymap handling
32-bit centric...essentially by redefining the set/get keymap ioctls a
bit (with backwards compatibility that guesses if the scancode is
16/24/32 bit based). It's been on my todo list for a long time to dust it
off...(yeah...I know)...
 
>0x[16-bit-address][16-bit-command]
>
>which encodes scancodes for extended NEC like this:
>0x[16-bit-address][~8-bit-command][8-bit-command]
>
>and normal NEC like this:
>0x[~8-bit-address][8-bit-address][~8-bit-command][8-bit-command]
>
>Thanks
>James

-- 
David Härdeman