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

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] [day] [month] [year] [list]
Message-ID: <ZxDDcHcNQLBP69Fy@gofer.mess.org>
Date: Thu, 17 Oct 2024 08:57:36 +0100
From: Sean Young <sean@...s.org>
To: 金超-软件项目部 <jinchao@...o.com>
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,

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