Em 28-07-2010 18:01, Maxim Levitsky escreveu: > On Wed, 2010-07-28 at 17:24 +0300, Maxim Levitsky wrote: >> On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote: >>> Em 28-07-2010 07:40, Jon Smirl escreveu: >>>> On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevit...@gmail.com> >>>> wrote: >>>>> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote: >>>>>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsm...@gmail.com> wrote: >>> >>>>> No its not, its just extended NEC. >>>> >>>> http://www.sbprojects.com/knowledge/ir/nec.htm >>>> Says the last two bytes should be the complement of each other. >>>> >>>> So for extended NEC it would need to be: >>>> 1100 0010 1010 0101 instead of 1100 0010 1010 0100 >>>> The last bit is wrong. >>>> >>>> From the debug output it is decoding as NEC, but then it fails a >>>> consistency check. Maybe we need to add a new protocol that lets NEC >>>> commands through even if they fail the error checks. >>> >>> Assuming that Maxim's IR receiver is not causing some bad decode at the >>> NEC code, it seems simpler to add a parameter at sysfs to relax the NEC >>> detection. We should add some way, at the userspace table for those RC's >>> that uses a NEC-like code. >>> >>> There's another alternative: currently, the NEC decoder produces a 16 bits >>> code for NEC and a 24 bits for NEC-extended code. The decoder may return a >>> 32 bits code when none of the checksum's match the NEC or NEC-extended >>> standard. >>> >>> Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so >>> there's no risk of generating a wrong keycode, if the wrong consistent check >>> is due to a reception error. >>> >>> Btw, we still need to port rc core to use the new tables ioctl's, as >>> cleaning >>> all keycodes on a 32 bits table would take forever with the current input >>> events ioctls. >>> >>>> It may also be >>>> that the NEC machine rejected it because the timing was so far off >>>> that it concluded that it couldn't be a NEC messages. The log didn't >>>> include the exact reason it got rejected. Add some printks at the end >>>> of the NEC machine to determine the exact reason for rejection. >>> >>> The better is to discard the possibility of a timing issue before changing >>> the decoder to accept NEC-like codes without consistency checks. >>> >>>> The current state machines enforce protocol compliance so there are >>>> probably a lot of older remotes that won't decode right. We can use >>>> some help in adjusting the state machines to let out of spec codes >>>> through. >>> >>> Yes, but we should take some care to avoid having another protocol decoder >>> to >>> interpret badly a different protocol. So, I think that the decoders may have >>> some sysfs nodes to tweak the decoders to accept those older remotes. >>> >>> We'll need a consistent way to add some logic at the remotes keycodes used >>> by >>> ir-keycode, in order to allow it to tweak the decoder when a keycode table >>> for >>> such remote is loaded into the driver. >>> >>>> User space lirc is much older. Bugs like this have been worked out of >>>> it. It will take some time to get the kernel implementation up to the >>>> same level. >>> >>> True. >> >> >> I more or less got to the bottom of this. >> >> >> It turns out that ENE reciever has a non linear measurement error. >> That is the longer sample is, the larger error it contains. >> Substracting around 4% from the samples makes the output look much more >> standard compliant. >> >> You are right that my remote has JVC protocol. (at least I am sure now >> it hasn't NEC, because repeat looks differently). >> >> My remote now actually partially works with JVC decoder, it decodes >> every other keypress. >> >> Still, no repeat is supported. >> >> However, all recievers (and transmitters) aren't perfect. >> Thats why I prefer lirc, because it makes no assumptions about protocol, >> so it can be 'trained' to work with any remote, and under very large >> range of error tolerances. >> >> Best regards, >> Maxim Levitsky >> > > I think I found the reason behind some of incorrect behavior. > > I see that in-kernel decoding is unhappy about the way I process gaps. > > I do exactly the same I did in lirc driver. > > At the end of keypress, the driver receives series of spaces from > hardware. > I accumulate 'em until patience^Wtimeout runs out. > Then I put hardware in 'idle' mode, and remember current time. > > As soon as I get new pulse, I send a sum of accumulated same and time > difference to user. > > Therefore every keypress ends with a pulse, and starts with space. > But in-kernel decoding isn't happy about it, it seems.. at least NEC > decoder... > > How you think to solve that? > Fix in-kernel decoders maybe?
Just send whatever you receive from hardware to the decoders. both LIRC and decoders have already a code to handle the timeouts. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
