Em Sat, 15 Dec 2012 03:12:58 +0200 Antti Palosaari <crope@xxxxxx> escreveu: > On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote: > > Em Sat, 15 Dec 2012 02:56:25 +0200 > > Antti Palosaari <crope@xxxxxx> escreveu: > > > >> NACK. NEC variant selection logic is broken by design. > > > > If you think so, then feel free to fix it without causing regressions to > > the existing userspace. > > > > While you don't do it, I don't see anything wrong on this patch, as it > > will behave just like any other NEC decoder. > > yes, so true as I mentioned end of the mail. Oh, I didn't saw your comments. Sorry. Please, next time, drop the part of the code that you're not commenting. On long emails like that, it is sometimes hard to see what's out there. I'll reply to your comments there again. > But it is very high > probability there is some non/wrong working keys when 32bit NEC variant > remote is used with that implementation. > > And what happened those patches David sends sometime ago. I remember > there was a patch for the af9015 which removes that kind of logic from > the driver. If not change NEC to 32bit at least heuristic could be moved > to single point - rc-core. There were some problems on his series, and it was breaking the userspace API. David made a new series, with a smaller set of patches that got applied, without those changes. The big issue there is to not break the current NEC userspace tables. Unfortunately, when the NEC software decoder was written, it were taking care only of the real NEC standard (the 24-bits and 32-bits variants aren't part of any spec I'm aware of). When we latter added support for those weird variants (RC-5 variants; Sony variants; NEC variants), it was decided, after long debates at the mailing list, to not create a new protocol for each, but, instead, to add support for them into the existing code. This is OK on most cases, as the variants are real variants, and the decoder can properly distinguish them. Unfortunately, NEC protocol variants don't fill on such case, as the only difference is that they doesn't honour to the checksum bytes. So, again after long discussions, it was decided to implement it the way it is. Changing it right now is not trivial, as it is easy to break existing userspace. Regards, 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
