Hi James, 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. > > 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). If the variant is really needed selecting it might be done in some other sysfs file. But I'd not implement it yet if we can manage without such logic. -Antti -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
