On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote: > Despite all discussions, we didn't reach an agreement yet. > > There are some points to consider whatever solution we do: > > 1) A keycode table should be able to work with a generic raw decoder. So, on all > drivers, the bit order and the number of bits for a given protocol should be the same; > > 2) we should avoid to cause regressions on the existing definitions. > > That's said, suggestions to meet the needs are welcome. Just to throw out some ideas: It appears to me that what you are looking at are communications protocols with a. a common Physical layer (PHY): a pulse distance protocol with a common carrier freq, bit symbol encoding, leader pulse, trailer pulse, and repeat sequence. The number of bits (and the leader pulse length?) is allowed to vary. b. differing Data Link layers (LL): the data link address can be different lengths and in different places; so can the data payload, so can the checks on address and data payload. For the end user, I would present each PHY/LL combination a different protocol. How the kernel implements it internally doesn't matter much. It could be one raw decoder handling all the PHY/LL combinations that it can, or one PHY decoder and several LL decoders. The keytables should probably be working on cooked LL output from the raw decoder. I think that will handle a lot of the issues you mention. The output from a LL could include destination address (from the transmitted code), source address (useful if different remotes can be detected), payload length, payload, and maybe button up/down. The LL could swallow the automatic repeats, since they are just part of the button up/down scheme. Aside from backward compatibility with existing keytables, I don't see much point in a decoder trying to flip bits from the PHY layer around to present a pseudo-PHY layer output. Don't keytables get updated with the kernel release anyway, or did they all move to userspace utils? Anyway, just some thoughts. Regards, Andy > Thanks, > Mauro -- 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
