On Monday 17 March 2014 19:01:51 Antti Seppälä wrote: > On 17 March 2014 00:41, James Hogan <james@xxxxxxxxxxxxx> 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:
signature.asc
Description: This is a digitally signed message part.
