lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a2149bb-9ac5-4cb0-9361-c292b66c214b@vivo.com>
Date: Sat, 12 Oct 2024 03:09:36 +0000
From: 金超-软件项目部 <jinchao@...o.com>
To: Sean Young <sean@...s.org>
CC: "mchehab@...nel.org" <mchehab@...nel.org>, 黄理鹏
	<huanglipeng@...o.com>, "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject:
 Re: 回复: [PATCH v1] media: rc-core: Modify the timeout waiting time for the infrared remote control.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ