| Message ID | 20240927105808.9284-1-shenlichuan@vivo.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] media: rc-core: Modify the timeout waiting time for the infrared remote control. | expand |
On Fri, Sep 27, 2024 at 06:58:08PM +0800, Shen Lichuan wrote: > When transmitting codes from certain infrared remote controls, the kernel > occasionally fails to receive them due to a timeout during transmission. > > This issue arises specifically in instances where the duration of the > signal exceeds the predefined limit (`IR_MAX_DURATION`) in the code > handling logic located within `lirc_dev.c`: > > if (txbuf[i] > IR_MAX_DURATION - duration || !txbuf[i]) { > pr_err("lirc_transmit duration out range[%d] txbuf:%d duration:%d\n", > i, txbuf[i], duration); > ret = -EINVAL; > goto out_kfree; > } > > The error manifests as an `EINVAL` (error number 22) being returned when > attempting to send infrared signals whose individual elements exceed the > maximum allowed duration (`xbuf[i] > IR_MAX_DURATION - duration`). > > As evidenced by logs, attempts to send commands with extended durations, > such as those associated with the "Power" button on a Skyworth TV remote, > fail with this error. > > To rectify this and ensure compatibility with a broader range of infrared > remote controls, particularly those with lengthy code sequences, this patch > proposes to increase the value of `IR_MAX_DURATION`. IR_MAX_DURATION is already half second; can you elaborate on the signal that the "Power" button on a Skyworth TV remote looks like? I doubt that a signal button press would produce more than 500ms of IR; that would be a lot IR for a single button, and would also have terrible latency for the user. My guess is that the signal is repeating, and you're trying to send the signals with the repeats in one go. It would be nice to hear what protocol this is and what it looks like encoded. If the signal contains large gaps/spaces, then the signal can be split up into multiple sends. For example, if you have this signal +100 -150000 +150 You can also send this like so (pseudo code): int fd = open("/dev/lirc0", O_RW); write(fd, [100], 1); usleep(150000); write(fd, [100], 1); close(fd); This overcomes the limitation of the IR_MAX_DURATION, and also makes it possible to send on much larger variety of infrared hardware, lots of them do not support sending large gaps or long signals. > This adjustment will allow for successful transmission of these extended > codes, thereby enhancing overall device compatibility and ensuring proper > functionality of remotes with long duration signals. > > Example log entries highlighting the issue: > D ConsumerIrHal: IRTX: Send to driver <268> > E ConsumerIrHal: irtx write fail, errno=22 <269> > D ConsumerIrHal: Done, Turn OFF IRTX <270> What software is this, anything you can share about it? > Modifying the maximum timeout time in this area can solve this issue. We hold various locks during the transmit, and keeping it to a minimum is much nicer. The gpio-ir-tx driver disables interrupts for this duration, and many other drivers hold the rcdev mutex. Thanks, Sean > > Signed-off-by: Huang Lipeng <huanglipeng@vivo.com> > Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> > --- > include/media/rc-core.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/media/rc-core.h b/include/media/rc-core.h > index d095908073ef..2f575c18b6b6 100644 > --- a/include/media/rc-core.h > +++ b/include/media/rc-core.h > @@ -303,7 +303,7 @@ struct ir_raw_event { > > #define US_TO_NS(usec) ((usec) * 1000) > #define MS_TO_US(msec) ((msec) * 1000) > -#define IR_MAX_DURATION MS_TO_US(500) > +#define IR_MAX_DURATION MS_TO_US(1000) > #define IR_DEFAULT_TIMEOUT MS_TO_US(125) > #define IR_MAX_TIMEOUT LIRC_VALUE_MASK > > -- > 2.17.1
在 2024/10/10 21:38, quqiwanzi 写道: > Dear Young > > IR_MAX_DURATION is already half second; can you elaborate on the signal > that the "Power" button on a Skyworth TV remote looks like? I doubt that > a signal button press would produce more than 500ms of IR; that would be > a lot IR for a single button, and would also have terrible latency for the > user. > > My guess is that the signal is repeating, and you're trying to send > the signals with the repeats in one go. It would be nice to hear what > protocol this is and what it looks like encoded. > > Abnormal encoding does not repeat sending compared to normal encoding, > but rather has a few extra lines of encoding causing timeout,the > infrared encoding is as follows > > 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, > 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 > > Abnormal :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, > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: IRTX: Send to driver > 10-09 11:19:53.973 1023 1023 E ConsumerIrHal: irtx write fail, errno=22 > > > > If the signal contains large gaps/spaces, then the signal can be split > up into multiple sends. For example, if you have this signal > > +100 -150000 +150 > > You can also send this like so (pseudo code): > > int fd = open("/dev/lirc0", O_RW); > write(fd, [100], 1); > usleep(150000); > write(fd, [100], 1); > close(fd); > > Currently unable to split into two shipments > > > > This adjustment will allow for successful transmission of these extended > > codes, thereby enhancing overall device compatibility and ensuring > proper > > functionality of remotes with long duration signals. > > > > Example log entries highlighting the issue: > > D ConsumerIrHal: IRTX: Send to driver <268> > > E ConsumerIrHal: irtx write fail, errno=22 <269> > > D ConsumerIrHal: Done, Turn OFF IRTX <270> > > What software is this, anything you can share about it? > > The kukong apk used sends the code by pressing the power button. > ConsumerIrHal is an MTK infrared remote control source file that > involves code confidentiality. Unfortunately, we are unable to provide > this part of the code > > Thanks ！ >> ------------------------------------------------------------------------ >> *发件人:* 黄理鹏 <huanglipeng@vivo.com> >> *发送时间:* 2024年10月8日 9:42 >> *收件人:* 金超-软件项目部 <jinchao@vivo.com> >> *主题:* 转发: [PATCH v1] media: rc-core: Modify the timeout waiting time >> for the infrared remote control. >> >> ------------------------------------------------------------------------ >> *发件人:* Sean Young <sean@mess.org> >> *发送时间:* 2024年10月3日 4:46 >> *收件人:* 沈李川 <shenlichuan@vivo.com> >> *抄送:* mchehab@kernel.org <mchehab@kernel.org>; 黄理鹏 >> <huanglipeng@vivo.com>; linux-media@vger.kernel.org >> <linux-media@vger.kernel.org>; linux-kernel@vger.kernel.org >> <linux-kernel@vger.kernel.org>; opensource.kernel >> <opensource.kernel@vivo.com> >> *主题:* Re: [PATCH v1] media: rc-core: Modify the timeout waiting time >> for the infrared remote control. >> On Fri, Sep 27, 2024 at 06:58:08PM +0800, Shen Lichuan wrote: >> > When transmitting codes from certain infrared remote controls, the >> kernel >> > occasionally fails to receive them due to a timeout during >> transmission. >> > >> > This issue arises specifically in instances where the duration of the >> > signal exceeds the predefined limit (`IR_MAX_DURATION`) in the code >> > handling logic located within `lirc_dev.c`: >> > >> > if (txbuf[i] > IR_MAX_DURATION - duration || !txbuf[i]) { >> > pr_err("lirc_transmit duration out range[%d] txbuf:%d >> duration:%d\n", >> > i, txbuf[i], duration); >> > ret = -EINVAL; >> > goto out_kfree; >> > } >> > >> > The error manifests as an `EINVAL` (error number 22) being returned >> when >> > attempting to send infrared signals whose individual elements >> exceed the >> > maximum allowed duration (`xbuf[i] > IR_MAX_DURATION - duration`). >> > >> > As evidenced by logs, attempts to send commands with extended >> durations, >> > such as those associated with the "Power" button on a Skyworth TV >> remote, >> > fail with this error. >> > >> > To rectify this and ensure compatibility with a broader range of >> infrared >> > remote controls, particularly those with lengthy code sequences, >> this patch >> > proposes to increase the value of `IR_MAX_DURATION`. >> >> IR_MAX_DURATION is already half second; can you elaborate on the signal >> that the "Power" button on a Skyworth TV remote looks like? I doubt that >> a signal button press would produce more than 500ms of IR; that would be >> a lot IR for a single button, and would also have terrible latency >> for the >> user. >> >> My guess is that the signal is repeating, and you're trying to send >> the signals with the repeats in one go. It would be nice to hear what >> protocol this is and what it looks like encoded. >> >> If the signal contains large gaps/spaces, then the signal can be split >> up into multiple sends. For example, if you have this signal >> >> +100 -150000 +150 >> >> You can also send this like so (pseudo code): >> >> int fd = open("/dev/lirc0", O_RW); >> write(fd, [100], 1); >> usleep(150000); >> write(fd, [100], 1); >> close(fd); >> >> This overcomes the limitation of the IR_MAX_DURATION, and also makes it >> possible to send on much larger variety of infrared hardware, lots of >> them >> do not support sending large gaps or long signals. >> >> > This adjustment will allow for successful transmission of these >> extended >> > codes, thereby enhancing overall device compatibility and ensuring >> proper >> > functionality of remotes with long duration signals. >> > >> > Example log entries highlighting the issue: >> > D ConsumerIrHal: IRTX: Send to driver <268> >> > E ConsumerIrHal: irtx write fail, errno=22 <269> >> > D ConsumerIrHal: Done, Turn OFF IRTX <270> >> >> What software is this, anything you can share about it? >> >> > Modifying the maximum timeout time in this area can solve this issue. >> >> We hold various locks during the transmit, and keeping it to a minimum >> is much nicer. The gpio-ir-tx driver disables interrupts for this >> duration, >> and many other drivers hold the rcdev mutex. >> >> Thanks, >> >> Sean >> >> > >> > Signed-off-by: Huang Lipeng <huanglipeng@vivo.com> >> > Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> >> > --- >> > include/media/rc-core.h | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/include/media/rc-core.h b/include/media/rc-core.h >> > index d095908073ef..2f575c18b6b6 100644 >> > --- a/include/media/rc-core.h >> > +++ b/include/media/rc-core.h >> > @@ -303,7 +303,7 @@ struct ir_raw_event { >> > >> > #define US_TO_NS(usec) ((usec) * 1000) >> > #define MS_TO_US(msec) ((msec) * 1000) >> > -#define IR_MAX_DURATION MS_TO_US(500) >> > +#define IR_MAX_DURATION MS_TO_US(1000) >> > #define IR_DEFAULT_TIMEOUT MS_TO_US(125) >> > #define IR_MAX_TIMEOUT LIRC_VALUE_MASK >> > >> > -- >> > 2.17.1 > >
Hi, 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. > 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); } 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
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
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 >
Hi, On Thu, Oct 17, 2024 at 07:15:21AM +0000, 金超-软件项目部 wrote: > > 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. So why print the decimal value 560 as 0x560? > > 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. 1) If you send repeats separately then no known protocol exceeds 0.5 seconds 2) There are databases of protocols, and no protocol here exceeds 0.5 seconds (or even comes near). http://hifi-remote.com/wiki/index.php/DecodeIR https://github.com/bengtmartensson/IrpTransmogrifier/blob/master/src/main/resources/IrpProtocols.xml The longest protocols I know of are for air conditioning units and I've never seen one longer than 0.5 seconds. 3) If a button press on a remote would take more than 0.5 seconds the latency would be awful, so no manufacturer would do this. Also, the chance of signal being corrupted during transmit would be quite high. 4) Some of the IR transmit hardware cannot handle such long transmits, e.g. mceusb, iguanair, redrat3 have limits on what can be sent due to usb packet limits. That means your software will never work with such hardware. 5) This limit has existed since the dawn of time in infrared. What has changed? > > In order to ensure the > > universality of the code and adapt to different situations, it would > > be better to directly modify IR-MAX_DURATION. I get the feeling you are trying to avoid the problem that you are sending the IR signal with the key repeats all at once. What driver are you using for transmit? Sean
Hi, Please send your emails in plain text only or they will be rejected by the list. On Fri, 2024-10-18 at 10:32 +0000, 金超-软件项目部 wrote: > 在 2024/10/17 15:57, Sean Young 写道: > > Hi, > > > > On Thu, Oct 17, 2024 at 07:15:21AM +0000, 金超-软件项目部 wrote: > > > 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. > > So why print the decimal value 560 as 0x560? > > The printing error here should be 560 > > > > 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: > > > > > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhifi-remote.com%2Fwiki%2Findex.php%2FNECx1&data=05%7C02%7Cjinchao%40vivo.com%7Cccbe2b0c91d344e44d6408dcee815f75%7C923e42dc48d54cbeb5821a797a6412ed%7C0%7C0%7C638647486650784417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=g442wKqtyI9uyQqq7iTcSB3ej4El39kd9Z51cI5mpa0%3D&reserved=0 > > > > > > > > > > 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. > > 1) If you send repeats separately then no known protocol exceeds > > 0.5 seconds > Now it is being sent separately and not duplicated. I have > confirmed with the remote control manufacturer that the code for > sending the power button will be over 500ms. The signal above is 61ms plus four repeats. If you add a ton of repeats yes, then sure, it becomes a lot longer. You haven't really engaged with the suggestion that you send signal plus repeats in separate calls to send. > The length of the power button code varies among different air > conditioning manufacturers. For example, the power button length of > Panasonic air conditioning is over 900ms, there may be codes over > 500ms I'm always interested to learn more about infrared protocols. Do you have any examples/documentation? > > 2) There are databases of protocols, and no protocol here exceeds > > 0.5 seconds > > (or even comes near). > > > > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhi > > fi- > > remote.com%2Fwiki%2Findex.php%2FDecodeIR&data=05%7C02%7Cjinchao%40v > > ivo.com%7Cccbe2b0c91d344e44d6408dcee815f75%7C923e42dc48d54cbeb5821a > > 797a6412ed%7C0%7C0%7C638647486650807965%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 > > %7C%7C%7C&sdata=UQijcgNqYDRV48noNxXewkdKlEYHldrAvFiq5DD5Aeg%3D&rese > > rved=0 > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > ithub.com%2Fbengtmartensson%2FIrpTransmogrifier%2Fblob%2Fmaster%2Fs > > rc%2Fmain%2Fresources%2FIrpProtocols.xml&data=05%7C02%7Cjinchao%40v > > ivo.com%7Cccbe2b0c91d344e44d6408dcee815f75%7C923e42dc48d54cbeb5821a > > 797a6412ed%7C0%7C0%7C638647486650821914%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 > > %7C%7C%7C&sdata=eSnjJeKxIF37B9PKxiW4cFqNjeYEALXqx59A3Lu%2FKro%3D&re > > served=0 > > The longest protocols I know of are for air conditioning units > > and I've > > never seen one longer than 0.5 seconds. > > > > 3) If a button press on a remote would take more than 0.5 seconds > > the latency > > would be awful, so no manufacturer would do this. Also, the > > chance of > > signal being corrupted during transmit would be quite high. > There may be some air conditioning manufacturers who set the power > button code to more than 500ms, but we have not found any issues such > as delay in our testing > > > > 4) Some of the IR transmit hardware cannot handle such long > > transmits, e.g. > > mceusb, iguanair, redrat3 have limits on what can be sent due to > > usb > > packet limits. That means your software will never work with > > such hardware. > > > > 5) This limit has existed since the dawn of time in infrared. What > > has changed? > Our software only runs on Android 15 and sends infrared signals by > scanning the air conditioning remote control. Therefore, the length > of the infrared signal depends on the infrared remote control, There > are no relevant changes, some air conditioning manufacturers send > power button codes that exceed 500ms So you're "learning" the codes from the existing remote and then just repeat it. Rather than sending it in one go, you can replace large gaps with a call to usleep(), e.g. anything above 20ms or so. > > > > In order to ensure the > > > > universality of the code and adapt to different situations, it > > > > would > > > > be better to directly modify IR-MAX_DURATION. > > > I get the feeling you are trying to avoid the problem that you are > > sending > > the IR signal with the key repeats all at once. > Communicate > with the manufacturer that the length of the power key code sent > here cannot be modified and must maintain signal integrity for at > least 500 milliseconds. What is signal integrity? What problem are you describing? Why does usleep() not work? > Therefore, > we hope to modify the delay from 500ms to 1000ms, which is more > suitable to match more air conditioning manufacturers Sure, I think we need to understand more about the air condition infrared protocols. The example you've given so far is not really showing anything special. > > What driver are you using for transmit? > > Use the infrared remote control driver provided by MTK for > > transmission, and the interface called by the program comes from > > kernel-6.6 I am confused. The mtk driver in drivers/media/rc/mtk-cir.c is receive only and has no support for transmitting. Do you have a modified mtk- cir driver or are you using gpio-ir-tx or pwm-ir-tx? The reason I ask is that some drivers take more locks that others, and it might be possible to do something depending on the driver. Sean
diff --git a/include/media/rc-core.h b/include/media/rc-core.h index d095908073ef..2f575c18b6b6 100644 --- a/include/media/rc-core.h +++ b/include/media/rc-core.h @@ -303,7 +303,7 @@ struct ir_raw_event { #define US_TO_NS(usec) ((usec) * 1000) #define MS_TO_US(msec) ((msec) * 1000) -#define IR_MAX_DURATION MS_TO_US(500) +#define IR_MAX_DURATION MS_TO_US(1000) #define IR_DEFAULT_TIMEOUT MS_TO_US(125) #define IR_MAX_TIMEOUT LIRC_VALUE_MASK
When transmitting codes from certain infrared remote controls, the kernel occasionally fails to receive them due to a timeout during transmission. This issue arises specifically in instances where the duration of the signal exceeds the predefined limit (`IR_MAX_DURATION`) in the code handling logic located within `lirc_dev.c`: if (txbuf[i] > IR_MAX_DURATION - duration || !txbuf[i]) { pr_err("lirc_transmit duration out range[%d] txbuf:%d duration:%d\n", i, txbuf[i], duration); ret = -EINVAL; goto out_kfree; } The error manifests as an `EINVAL` (error number 22) being returned when attempting to send infrared signals whose individual elements exceed the maximum allowed duration (`xbuf[i] > IR_MAX_DURATION - duration`). As evidenced by logs, attempts to send commands with extended durations, such as those associated with the "Power" button on a Skyworth TV remote, fail with this error. To rectify this and ensure compatibility with a broader range of infrared remote controls, particularly those with lengthy code sequences, this patch proposes to increase the value of `IR_MAX_DURATION`. This adjustment will allow for successful transmission of these extended codes, thereby enhancing overall device compatibility and ensuring proper functionality of remotes with long duration signals. Example log entries highlighting the issue: D ConsumerIrHal: IRTX: Send to driver <268> E ConsumerIrHal: irtx write fail, errno=22 <269> D ConsumerIrHal: Done, Turn OFF IRTX <270> Modifying the maximum timeout time in this area can solve this issue. Signed-off-by: Huang Lipeng <huanglipeng@vivo.com> Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> --- include/media/rc-core.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)