Hi May I ask if there has been any progress on this issue? It affects the user experience and could you please take a look as soon as possible? Thank you 在 2024/10/12 11:09, quqiwanzi 写道: > Hi > > 在 2024/10/11 22:34, Sean Young 写道: >> On Wed, Oct 09, 2024 at 07:03:57AM +0000, 金超-软件项目部 wrote: >>> NORMAL: The kukong apk control remote control sends codes for other >>> buttons >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[0]: 4500, >>> 4500, 560, 560, 560, 1680, 560, 1680 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[8]: 560, >>> 1680, 560, 560, 560, 560, 560, 560 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[16]: 560, >>> 560, 560, 560, 560, 1680, 560, 1680 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[24]: 560, >>> 1680, 560, 560, 560, 560, 560, 560 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[32]: 560, >>> 560, 560, 1680, 560, 560, 560, 1680 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[40]: 560, >>> 1680, 560, 560, 560, 560, 560, 560 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[48]: 560, >>> 560, 560, 560, 560, 1680, 560, 560 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[56]: 560, >>> 560, 560, 1680, 560, 1680, 560, 1680 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[64]: 560, >>> 1680, 560, 46920, 4500, 4500, 560, 1680 >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x560, >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x96200, >> If I sum all these lengths, I get 216000 microseconds. That's well clear >> of IR_MAX_DURATION (500ms). >> >> Note that the last two values 0x560 and 0x96200 look really weird, >> they are >> not hex values are all, and there is no "pattern[...]: " prefix. > This is to iterate through the remaining parts that are less than > eight digits and print them out. > > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x560, > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x96200, > >>> 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: >>> 10-09 11:20:18.220 1023 1023 D ConsumerIrHal: IRTX: Send to driver >>> 10-09 11:20:18.469 1023 1023 D ConsumerIrHal: Done, Turn OFF IRTX >>> >>> SPECIAL :Sending the power button on the remote control of the >>> kukong app may result in additional lines of coding, leading to >>> transmission failure (72-88 extra) >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[0]: 4500, >>> 4500, 560, 560, 560, 1680, 560, 1680 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[8]: 560, >>> 1680, 560, 560, 560, 560, 560, 560 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[16]: 560, >>> 560, 560, 560, 560, 1680, 560, 1680 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[24]: 560, >>> 1680, 560, 560, 560, 560, 560, 560 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[32]: 560, >>> 560, 560, 560, 560, 560, 560, 1680 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[40]: 560, >>> 1680, 560, 560, 560, 560, 560, 560 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[48]: 560, >>> 560, 560, 1680, 560, 1680, 560, 560 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[56]: 560, >>> 560, 560, 1680, 560, 1680, 560, 1680 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[64]: 560, >>> 1680, 560, 46920, 4500, 4500, 560, 1680 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[72]: 560, >>> 96200, 4500, 4500, 560, 1680, 560, 96200 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[80]: 4500, >>> 4500, 560, 1680, 560, 96200, 4500, 4500 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[88]: 560, >>> 1680, 560, 96200, 4500, 4500, 560, 1680 >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: 0x560, >>> 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: 0x96200, >> If I sum all these lengths I get 648000 microseconds, so quit a bit more >> than IR_MAX_DURATION, which is why the send fails. Again the last two >> values >> are printed like garbage. >> >> The signal looks like NECx1: >> http://hifi-remote.com/wiki/index.php/NECx1 >> >> So there is the main signal, follow by a bunch of repeats. Each repeat >> looks like +4500 -4500 +560 -1680 +560 -96200; the -96200 is the >> trailing >> gap. To avoid going over IR_MAX_DURATION, don't include the -96200 gap >> but replaced with a usleep(96200), i.e. in psuedo code: >> >> int i, fd = open("/dev/lirc0", O_RDWR); >> write(fd, [4500 4500 560 560 560 1680 560 1680 560 1680 560 >> 560 560 560 560 560 560 560 560 560 560 1680 560 1680 560 1680 560 >> 560 560 560 560 560 560 560 560 560 560 560 560 1680 560 1680 560 560 >> 560 560 560 560 560 560 560 1680 560 1680 560 560 560 560 560 1680 >> 560 1680 560 1680 560 1680 560]); >> usleep(46920); >> for (i=0; i<4; i++) { >> write(fd, [4500 4500 560 1680 560]); >> usleep(96200); >> } > > Thank you for your suggestion. The infrared code here is the power key > code sent through the Kukong remote control, and there may be other > infrared codes that exceed IR-MAX_DURATION. In order to ensure the > universality of the code and adapt to different situations, it would > be better to directly modify IR-MAX_DURATION. > > >> >> Note that this what the lirc daemon also does for transmits; it's a well >> established way of sending. The write() to a lirc chardev won't >> return until >> the transmit has been successful. It might be interruptted by a >> signal, so >> you should disable signals during write (I don't think lirc daemon >> bothers >> though). >> >> >> Hope this helps >> >> Sean > > > Thank you for providing suggestions. Looking forward to your reply > > Chao >
