Re: Can I expect in-kernel decoding to work out of box?

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Wed, 2010-07-28 at 17:13 -0300, Mauro Carvalho Chehab wrote: 
> Andy,
> 
> Em 28-07-2010 15:18, Andy Walls escreveu:
> > On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote:
> >> On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> >>> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
> >>>> Em 28-07-2010 11:53, Jon Smirl escreveu:
> >>>>> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> >>>>>> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> >>>
> >>>>> I recommend that all decoders initially follow the strict protocol
> >>>>> rules. That will let us find bugs like this one in the ENE driver.
> >>>>
> >>>> Agreed.
> >>>
> >>> Well...
> >>>
> >>> I'd possibly make an exception for the protocols that have long-mark
> >>> leaders.  The actual long mark measurement can be far off from the
> >>> protocol's specification and needs a larger tolerance (IMO).
> >>>
> >>> Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
> >>> protocol element that is 8 to 16 protocol time units long, doesn't make
> >>> too much sense to me.  If the remote has the basic protocol time unit
> >>> off from our expectation, the error will likely be amplified in a long
> >>> protocol elements and very much off our expectation.
> >>
> >> Do you have a better way to differentiate JVC and NEC protocols? They
> >> are pretty similar except for the timings.
> > 
> > Yes: Invoke the 80/20 rule and don't try.
> 
> At the room where my computers is located, I have two wide fluorescent lamps
> each with 20W. If I don't hide the IR sensors bellow my desk, those lamps
> are enough to generate random flickers at the sensors. With the more relaxed
> driver we used to have at saa7134, it ended by producing random scancodes,
> or, even worse, random repeat codes. So, lots of false-positive events. It is
> a way worse to have false-positive than having a false-negative events.
> 
> So, I don't think it is a good idea to use a "relaxed" mode by default.
> 
> 
> > Enable NEC and disable JVC by
> > default.  Let the users know so as to properly manage user expectations.
> > (Maxim's original question was about expectation.)
> 
> We should discuss a little bit about RC subsystem evolution during LPC/2010, 
> but, from my point of view, we should soon deprecate the in-kernel keymap tables
> on some new kernel version, using, instead, the ir-keycode application to 
> dynamically load the keycode tables via UDEV. Of course, after some time,
> we may end by removing all those tables from the kernel.
/me is very happy about it.
The reason isn't even about size or some principle.
These keymaps just increase compilation time too much...

> 
> So, assuming that we follow this patch, what we'll have for a newer device is:
> 
> For most devices, the keymap configuration table (rc_maps.cfg) will associate
> all known devices with their corresponding keytable (we still need to generate
> a default rc_maps.cfg that corresponds to the current in-kernel mapping, but
> this is trivial).
> 
> As ir-keytable disables all protocols but the one(s) needed by a given device,
> in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled.
> If the table is for JVC, NEC will be disabled.
> 
> So, this already happens in a practical scenario, as all decoders will be enabled 
> only before loading a keymap (or if the user explicitly enable the other decoders).
> 
> So, the device will be in some sort of "training" mode, e. g. it will try every
> possible decoder, and will be generating the scancodes for some userspace application
> that will be learning the keycodes and creating a keymap table.
> 
> IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a
> "relaxed" mode only when the user (or the userspace app) detects that there's something
> wrong with that device.
> 
> > When the user knows NEC isn't working, or he suspects JVC may work, he
> > can bind that protocol to the particular IR receiver.
> > 
> > Trying to solve the discrimination problem with blindly parallel
> > decoding all the possible protocols is a big waste of effort IMO:
> > 
> > a. Many remotes are sloppy and out of spec, and get worse with weak
> > batteries.
> > 
> > b. The IR receiver driver knows what remotes possibly came bundled with
> > the hardware.  (For the case of the MCE USB, it's almost always an RC-6
> > 6A remote.)
> > 
> > c. The user can tell the kernel about his remote unambiguously.
> > 
> > There's no burning need to wear a blindfold, AFAICT, so let's not.
> > 
> > Why bother to solve a hard problem (discrimination of protocols from out
> > of spec remotes), when it raises the error rate of solving the simple
> > one (properly decoding a single protocol)?
> > 
> > Doing many things poorly is worse than doing one thing well.
> > Non-adaptive protocol discovery (i.e. blind parallel decoding) should
> > not be the default if it leads to problems or inflated expectations for
> > the user.
> > 
> > 
> >>  What happened in this case
> >> was that the first signals matched the NEC protocol. Then we shifted
> >> to bits that matched JVC protocol.
> >>
> >> The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5%
> >> error in the initial bit you can't separate the protocols.
> >>
> >> In general the decoders are pretty lax and the closest to the correct
> >> one with decode the stream. The 50% rule only comes into play between
> >> two very similar protocols.
> >>
> >> One solution would be to implement NEC/JVC in the same engine. Then
> >> apply the NEC consistency checks. If the consistency check pass
> >> present the event on the NEC interface. And then always present the
> >> event on the JVC interface.
> > 
> > It's just too simple to have the user:
> > 
> > a. Try NEC
> > b. Try JVC
> > c. Make a judgment and stick with the one he perceives works.
> > 
> > 
> > To have reliable discrimination in the general case between two
> > protocols, given the variables out of our control (i.e. the remote
> > control implementation) would require some sort of data collection and
> > adaptive algorithm to go on inside the kernel.  I don't think you can
> > get reliable discrimination in one key press.  Maybe by looking at the
> > key press and the repeats together might up the probability of correct
> > discrimination (that's one criterion you examined to make a
> > determination in your earlier email).
> 
> Cheers,
> Mauro.