From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0CCFC43334 for ; Mon, 27 Jun 2022 10:53:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234367AbiF0Kx4 (ORCPT ); Mon, 27 Jun 2022 06:53:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233895AbiF0Kxz (ORCPT ); Mon, 27 Jun 2022 06:53:55 -0400 Received: from gofer.mess.org (gofer.mess.org [IPv6:2a02:8011:d000:212::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79F84640E for ; Mon, 27 Jun 2022 03:53:54 -0700 (PDT) Received: by gofer.mess.org (Postfix, from userid 1000) id B296610007F; Mon, 27 Jun 2022 11:53:52 +0100 (BST) Date: Mon, 27 Jun 2022 11:53:52 +0100 From: Sean Young To: Marko =?iso-8859-1?B?TeRrZWzk?= Cc: linux-media@vger.kernel.org Subject: Re: [PATCH 2/2] media: rtl28xxu: improve IR receiver Message-ID: References: <704b3d7e5a7a95cbd5e4dfc25a41454e919aed95.1644683294.git.sean@mess.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Marko, On Sun, Jun 26, 2022 at 03:33:47PM +0300, Marko Mäkelä wrote: > I finally took the time to get a deeper understanding of the infrared remote > control subsystem. I think that I now understand the translation into > key-down, key-up, and key-repeat events. For the RC5 protocol, rc_repeat() > will not be called by ir-rc5-decoder.c but instead, ir_do_keydown() will > handle the repeat. For lirc_scancode_event() it will never set the > LIRC_SCANCODE_FLAG_REPEAT bit, even if !new_event and the protocol does > support the toggle bit. That might qualify as a bug. You are right, this was missed. Patches welcome. > Sat, Feb 12, 2022 at 04:32:19PM +0000, Sean Young wrote: > > This device presents an IR buffer, which can be read and cleared. > > Clearing the buffer is racey with receiving IR, so wait until the IR > > message is finished before clearing it. > > > > This should minimize the chance of the buffer clear happening while > > IR is being received, although we cannot avoid this completely. > > I just realized that this limitation of the interface may be causing exactly > what I was observing when I was testing this. If a constant stream of data > is being received because a button is being held down, a buffer overflow or > wrap-around glitch is inevitable, maybe expect if the wrap-around occurs > exactly at the 128-byte boundary. > > How about the following improvement? If IR_RX_BC is a simple cursor to the > 128-byte IR_RX_BUF, then rtl2832u_rc_query() could avoid sending > refresh_tab[] but simply remember where the previous call left off. We could > always read the 128 bytes at IR_RX_BUF, and process everything between the > previous position reported by IR_RX_BC and the current position reported by > IR_RX_BC, and treat buf[] as a ring buffer. This is a great idea. Very original. > Last time I tested it, the patch was a significant improvement. I think that > "perfect" is the enemy of "good enough", and the patch should be included in > the kernel. The idea sounds really good. I'll review/test the patch and get back to you. Thanks, Sean