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

[James Hogan <james@albanarts.com>]

[-- Attachment #1: Type: text/plain, Size: 3165 bytes --]

On Monday 17 March 2014 19:01:51 Antti Seppälä wrote:
> On 17 March 2014 00:41, James Hogan <james@albanarts.com> wrote:
> > Yeh I'm in two minds about this now. It's actually a little awkward since
> > some of the protocols have multiple variants (i.e. "rc-5" = RC5+RC5X),
> > but an encoded message is only ever a single variant, so technically if
> > you're going to draw the line for wakeup protocols it should probably be
> > at one enabled variant, which isn't always convenient or necessary.
> 
> I'd very much prefer to have the selector as it currently is -
> protocol groups instead of variants which would keep it consistent
> with decoding protocol selection.

Yeh, I'll submit a patch to fix wakeup-protocols to disallow multiple groups 
of protocols from being enabled at the same time.

> > Note, ATM even disallowing "+proto" and "-proto" we would already have to
> > guess which variant is desired from the scancode data, which in the case
> > of
> > NEC scancodes is a bit horrid since NEC scancodes are ambiguous. This
> > actually means it's driver specific whether a filter mask of 0x0000ffff
> > filters out NEC32/NEC-X messages (scancode/encode driver probably will
> > since it needs to pick a variant, but software fallback won't).
> 
> How common is it that NEC codes are really ambiguous? Or that a wrong
> variant is selected for encoding? A quick look suggests that the
> length of the scancode will be good enough way to determine which
> variant is used for NEC, RC-5(X) and RC-6(A).

When I tried filtering for my TV remote it didn't work. It turned out to be 
because the extended nec scancode has the address bytes in the wrong order so 
that the bits are discontinuous compared to the raw data. The remote uses 
extended NEC but has zero in the lower byte of the address, which 
unfortunately goes in bits 23:16 of the scancode above the other byte of the 
address, so it looks as if it's using normal NEC (16bit scancodes). This is 
why I ended up making img-ir use the mask too in the decision.

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:
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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]