Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em Sat, 15 Dec 2012 03:12:58 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
> > Em Sat, 15 Dec 2012 02:56:25 +0200
> > Antti Palosaari <crope@iki.fi> 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