[BUG] keybow2040: RGB causing infinite loop

[JimMadge]

Describe the bug
When using the example keybow2040 configuration, current CircuitPython and current kmk library, button presses have no effect. After a while CircuitPython soft resets.

Disabling the RGB, or forcing an exit from the _process_timeouts loop is a workaround.

To Reproduce
Steps to reproduce the behavior:

• Firmware 85658f6
• Unmodified keybow2040 files
• Adafruit CircuitPython IS31FL3731 3.3.9
• Plug in keyboard

Expected behavior
Keyboard responds to button presses.

Debug output

75001 kmk.keyboard: Unexpected error: cleaning up

Code stopped by auto-reload. Reloading soon.
soft reboot

repeatedly (different numbers)

Additional context

• When using the unmodified keybow2040 configuration, the RGB cycles colours but key presses have no effect.
• If you disable RGB (by commenting )
  

  kmk_firmware/boards/pimoroni/keybow_2040/code.py

  Line 15 in 4b5d6a3

  keybow.extensions = [rgb_ext]

  
  key presses work as expected
• Trying to find out what was happening, I found that _process_timouts() never returns.
  The loop does not end.
  

  kmk_firmware/kmk/kmk_keyboard.py

  Lines 275 to 277 in 4b5d6a3

  	def _process_timeouts(self) -> None:
  	for task in get_due_task():
  	task()

  
  If you force this loop to exit early (say, by calling return after 10 iterations), key presses again work, but the RGB stops cycling.

So, I suspect that calls to update the RGB LEDs are filling the task queue and preventing the HID functions in go from being called.

I'm not very familiar with async but I'm happy to help debug if you have any suggestions.

[JeffreyStocker]

I am having the same issue. I just started to play with RGB module and noticed that the keypad would become unresponsive to key presses when one of the more intricate RGB sequences were selected.

Ones tried

• KC.RGB_MODE_SWIRL
• KC.RGB_MODE_BREATHE_RAINBOW
• KC.RGB_MODE_RAINBOW

KC.RGB_MODE_PLAIN and KC.RGB_MODE_BREATHE don't appear to be affected.

One workaround is to throttle the RGB updates via the refresh_rate setting

#from [RGB Document](https://github.com/KMKfw/kmk_firmware/blob/master/docs/en/rgb.md)
from kmk.extensions.rgb import AnimationModes
rgb = RGB(pixel_pin=rgb_pixel_pin,
        num_pixels=27
        val_limit=100,
        hue_default=0,
        sat_default=100,
        rgb_order=(1, 0, 2),  # GRB WS2812
        val_default=100,
        hue_step=5,
        sat_step=5,
        val_step=5,
        animation_speed=1,
        breathe_center=1,  # 1.0-2.7
        knight_effect_length=3,
        animation_mode=AnimationModes.STATIC,
        reverse_animation=False,
        refresh_rate=60,  # <---------- set to a lower setting
        )

On mine I found that 35 appears to be the upper limit, but key press start to get unreliable. Lower is better but it makes the RGB update slowly

Hardware:
Adafruit MacroPad RP2040

[JimMadge]

#862 is an improvement but my board still isn't behaving quite as expected.

Keypress are now sometimes registered. However if it is, characters are repeated many times as if they HID signal is being repeatedly sent or the key is being held down. (e.g. "aaaaaaaaaa").

Thanks @xs5871 for proposing a fix so quickly 🎉.
I commented here because I didn't want to hold up that PR. It is an improvement but I don't think it fixes this problem completely.
Happy to help continue testing branches or with anything debugging I can do.

[xs5871]

You're right that #862 only fixes the infinite loop.

Keypress are now sometimes registered. However if it is, characters are repeated many times as if they HID signal is being repeatedly sent or the key is being held down. (e.g. "aaaaaaaaaa").

That is the "expected" behaviour and unintuitively not a bug. Compounding factors are:

• some RGB animations takes a long time to compute
• writing to the pixelbuffer is a blocking operation
• there are lots of LEDs
• animation refresh rate is too high

[JimMadge]

That makes sense.

Would a sensible thing be to change the keybow2040 example to use a less expensive RGB animation?

Happy to play around with that to find something that makes the keyboard more responsive.

[JeffreyStocker]

Funny you should say that. I was playing around with the RGB and found a way to increase the RGB update efficiency.
#864
I found that this allowed me to go from refresh_rate of 35ish to over 200 before issues started to appear
YMMV since I'm using a tiny macropad

[JimMadge]

@JeffreyStocker #864 Doesn't seem to make much difference on my Keybow2040. It still isn't really usable with the more intense RGB animations.

[JeffreyStocker]

@JimMadge Check your refresh_rate that your passing into the RGB module. See what happens when you lower the refresh_rate

One thing I'm seeing, looking at the spec page of the Keybow2040 is that it is using a LED matrix driver, (maybe a custom code to control it?)

The way Neopixels and many strip LED work is by a message to the first LED and then that LED pass the message to the next LED. So I'm the code is gaining a lot of performance I'm having only 1 message be sent per update cycle, rather than 12 messages (I have 12 LEDS).
I'm not sure how the Keybow2040 is sending LED updates. Could you show what your RGB initiation variables and what libraries you are importing?