Re: [PATCH v1] media: rc-core: Modify the timeout waiting time for the infrared remote control.

From: 金超-软件项目部
Date: Thu Oct 10 2024 - 22:02:18 EST

Next message: Wei Fang: "RE: [PATCH net-next 10/11] net: enetc: add preliminary support for i.MX95 ENETC PF"
Previous message: Joseph Qi: "Re: [PATCH V2] ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

在 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@xxxxxxxx>
>> *发送时间:* 2024年10月8日 9:42
>> *收件人:* 金超-软件项目部 <jinchao@xxxxxxxx>
>> *主题:* 转发: [PATCH v1] media: rc-core: Modify the timeout waiting time
>> for the infrared remote control.
>>
>> ------------------------------------------------------------------------
>> *发件人:* Sean Young <sean@xxxxxxxx>
>> *发送时间:* 2024年10月3日 4:46
>> *收件人:* 沈李川 <shenlichuan@xxxxxxxx>
>> *抄送:* mchehab@xxxxxxxxxx <mchehab@xxxxxxxxxx>; 黄理鹏
>> <huanglipeng@xxxxxxxx>; linux-media@xxxxxxxxxxxxxxx
>> <linux-media@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
>> <linux-kernel@xxxxxxxxxxxxxxx>; opensource.kernel
>> <opensource.kernel@xxxxxxxx>
>> *主题:* 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@xxxxxxxx>
>> > Signed-off-by: Shen Lichuan <shenlichuan@xxxxxxxx>
>> > ---
>> > 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
>
>

Next message: Wei Fang: "RE: [PATCH net-next 10/11] net: enetc: add preliminary support for i.MX95 ENETC PF"
Previous message: Joseph Qi: "Re: [PATCH V2] ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]