[PATCH] media: rc: nec: Treat a full NEC command frame as a fresh keypress

[PATCH] media: rc: nec: Treat a full NEC command frame as a fresh keypress

[Fabio Estevam]

NEC sends one full command frame per keypress, followed by short repeat
frames while the button remains held. The decoder already distinguishes
these cases and reports them through rc_keydown() and rc_repeat().

Without a toggle bit, rc-core treats a second command with the same
scancode inside the key-up timeout as part of the existing press. The
second tap therefore loses its key-down event. Call rc_keyup() before
reporting each full command frame so rc-core recognizes a fresh press.
Repeat frames still use rc_repeat() and remain unchanged.

Measured on a Ruwido Z3 over a 1.2 s hold: one command frame followed
by 11 repeat frames. Command and repeat header spaces were 4.5 ms and
2.2 ms, respectively, with no overlap.

NEC remotes that repeat full command frames while held will instead
produce press/release trains.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
 drivers/media/rc/ir-nec-decoder.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/rc/ir-nec-decoder.c b/drivers/media/rc/ir-nec-decoder.c
index 37b99432ad0d..4357413763ca 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -153,6 +153,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev)
 			if (data->is_nec_x)
 				data->necx_repeat = true;
 
+			rc_keyup(dev);
 			rc_keydown(dev, rc_proto, scancode, 0);
 		} else {
 			rc_repeat(dev);
-- 
2.43.0

Re: [PATCH] media: rc: nec: Treat a full NEC command frame as a fresh keypress

[Sean Young]

On Mon, Oct 19, 2026 at 10:33:31PM -0300, Fabio Estevam wrote:
> NEC sends one full command frame per keypress, followed by short repeat
> frames while the button remains held. The decoder already distinguishes
> these cases and reports them through rc_keydown() and rc_repeat().
> 
> Without a toggle bit, rc-core treats a second command with the same
> scancode inside the key-up timeout as part of the existing press. The
> second tap therefore loses its key-down event. Call rc_keyup() before
> reporting each full command frame so rc-core recognizes a fresh press.
> Repeat frames still use rc_repeat() and remain unchanged.
> 
> Measured on a Ruwido Z3 over a 1.2 s hold: one command frame followed
> by 11 repeat frames. Command and repeat header spaces were 4.5 ms and
> 2.2 ms, respectively, with no overlap.
> 
> NEC remotes that repeat full command frames while held will instead
> produce press/release trains.
> 
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
>  drivers/media/rc/ir-nec-decoder.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/rc/ir-nec-decoder.c b/drivers/media/rc/ir-nec-decoder.c
> index 37b99432ad0d..4357413763ca 100644
> --- a/drivers/media/rc/ir-nec-decoder.c
> +++ b/drivers/media/rc/ir-nec-decoder.c
> @@ -153,6 +153,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev)
>  			if (data->is_nec_x)
>  				data->necx_repeat = true;
>  
> +			rc_keyup(dev);

I'm sorry, this is simply not correct. There are nec remotes which send the
full nec code (so no repeat) at least times when you press any button. As
long as the button is pressed, the code is repeated.

If you want to distinct keypresses for when a button is held down, use the
input autorepeat feature. You can adjust it with ir-keytable -D and
ir-keytable -P.

Thanks,

Sean

>  			rc_keydown(dev, rc_proto, scancode, 0);
>  		} else {
>  			rc_repeat(dev);
> -- 
> 2.43.0
>