[Bug] Work Louder Micro RGB Matrix flicker after macropad start/wakeup

[ForsakenRei]

Describe the Bug

Recently notice my macropad has a RGB Matrix (per key LED) flicker issue when the board start or wake up from sleep.
RGB Light (under glow) seems totally fine, but RGB Matrix (per key LED) will flicker for at least a few seconds once the board was connected, or wake the host up from sleep. It's not 100% reproducable but most of the times it is there.
Usually it will stop after a few seconds but sometimes it just keep flickering until I send QK_RBT or disconnect and re-connect the board.

I use my own kepmap here https://github.com/ForsakenRei/qmk-worklouder-micro
but I did try the pure default keymap and it has the same issue.

Not sure if disable RGB matrix totally will fix this issue but this macropad is a little different from other boards I have, especially for that rgb_functions.c sourced in rules.mk.

Keyboard Used

work_louder/micro

Link to product page (if applicable)

No response

Operating System

Windows 10/11

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.6
Ψ QMK home: C:/Users/{username}/qmk_firmware
Ψ Detected Windows 10 (10.0.19045).
Ψ QMK MSYS version: 1.10.0
Ψ Userspace enabled: False
Ψ Git branch: master
Ψ Repo version: 0.27.9
⚠ Git has unstashed/uncommitted changes.
Ψ - Latest master: 2025-01-15 14:36:20 -0500 (7b83bb9d26) -- Allow running Docker container on MacOS (without in-container USB support) (#24412)
Ψ - Latest upstream/master: 2025-01-15 14:36:20 -0500 (7b83bb9d26) -- Allow running Docker container on MacOS (without in-container USB support) (#24412)
Ψ - Latest upstream/develop: 2025-01-15 19:36:54 +0000 (1174d16b5a) -- Merge remote-tracking branch 'origin/master' into develop
Ψ - Common ancestor with upstream/master: 2025-01-15 14:36:20 -0500 (7b83bb9d26) -- Allow running Docker container on MacOS (without in-container USB support) (#24412)
Ψ - Common ancestor with upstream/develop: 2025-01-15 14:36:20 -0500 (7b83bb9d26) -- Allow running Docker container on MacOS (without in-container USB support) (#24412)
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 13.3.0
Ψ Successfully compiled using arm-none-eabi-gcc
Ψ Successfully tested arm-none-eabi-binutils using arm-none-eabi-size
Ψ Found avr-gcc version 14.2.0
Ψ Successfully compiled using avr-gcc
Ψ Successfully tested avr-binutils using avr-size
Ψ Found avrdude version 7.3-2024041
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2024-02-17 19:20:06 +0000 --  (be44b3305f)
Ψ - lib/chibios-contrib: 2024-04-03 20:39:24 +0800 --  (77cb0a4f)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go, but minor problems were found

I removed all the keymaps I didn't need so there are uncommited changes.

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

N/A

Additional Context

No response

[ForsakenRei]

Not sure if this has anything to do with USB drivers but I noticed if I connect/disconnect a different USB device, say another keyboard it will also flicker for a few seconds...? Not every time/every device but I have tried two keyboards, 1 usb drive and 1 security key and they all can cause it to flicker, uh

OK now I tried 3 different machines, the issue was still there so it might not be a per machine driver issue.

[drashna]

It may be worth lowering the brightness for both rgb light and rgb matrix, as it may be pulling too much power and tripping things.

[ForsakenRei]

It may be worth lowering the brightness for both rgb light and rgb matrix, as it may be pulling too much power and tripping things.

I suspect that earlier so I set the max brightness for rgb_matrix to be 0 and rgblight to be 150 in keyboard.json but it still happens, for some reason. I didn't find a proper way to fully disable rgb_matrix though, the rgb_functions.c source in rules.mk is a little tricky with my little understanding of qmk lol.

[ForsakenRei]

Got back home and tried set rgblight max brightness to 100 and 80 but everything looks the same, and it's still flickering after I flash the firmware...
If I disconnect a usb device and reconnect it back it will ficker for a few seconds only, but flashing firmware it seems to be flickering until I reboot the board, or reconnect it.

[ForsakenRei]

Can confirm this still persist on 0.28, while without changes related to the board itself I'm not expecting it gets fixed magically...

[ForsakenRei]

Latest 0.29.11 has the same issue, though I found as long as I spin the encoder a few times the flickering goes away.

[drashna]

get-reuer's lumino module may help here, if there is enough room in the firmware.

That said, if the brightness setting doesn't help, then this simply may be a limitation/issue with using 2 different data pins for ws2812, as QMK doesn't support that natively, and whe work louder boards are using a hack to enable support for it. The driver uses hard stops (eg, hard locks) for timing for the ws2812 led driver, and it may be causing it to fall out of spec just enough to cause issues.

Tweaking the timing for the driver may help. Eg, these settings:

qmk_firmware/drivers/led/ws2812.h

Lines 20 to 49 in f31004e

	/*
	* The WS2812 datasheets define T1H 900ns, T0H 350ns, T1L 350ns, T0L 900ns. Hence, by default, these
	* are chosen to be conservative and avoid problems rather than for maximum throughput; in the code,
	* this is done by default using a WS2812_TIMING parameter that accounts for the whole window (1250ns)
	* and defining T1H and T0H; T1L and T0L are obtained by subtracting their low counterparts from the window.
	*
	* However, there are certain "WS2812"-like LEDs, like the SK6812s, which work in a similar
	* communication topology but use different timings for the window and the T1L, T1H, T0L and T0H.
	* This means that, albeit the same driver being applicable, the timings must be adapted.
	*/
	#ifndef WS2812_TIMING
	# define WS2812_TIMING 1250
	#endif
	#ifndef WS2812_T1H
	# define WS2812_T1H 900 // Width of a 1 bit in ns
	#endif
	#ifndef WS2812_T1L
	# define WS2812_T1L (WS2812_TIMING - WS2812_T1H) // Width of a 1 bit in ns
	#endif
	#ifndef WS2812_T0H
	# define WS2812_T0H 350 // Width of a 0 bit in ns
	#endif
	#ifndef WS2812_T0L
	# define WS2812_T0L (WS2812_TIMING - WS2812_T0H) // Width of a 0 bit in ns
	#endif

[ForsakenRei]

get-reuer's lumino module may help here, if there is enough room in the firmware.

That said, if the brightness setting doesn't help, then this simply may be a limitation/issue with using 2 different data pins for ws2812, as QMK doesn't support that natively, and whe work louder boards are using a hack to enable support for it. The driver uses hard stops (eg, hard locks) for timing for the ws2812 led driver, and it may be causing it to fall out of spec just enough to cause issues.

Tweaking the timing for the driver may help. Eg, these settings:

qmk_firmware/drivers/led/ws2812.h

Lines 20 to 49 in f31004e

/*

• The WS2812 datasheets define T1H 900ns, T0H 350ns, T1L 350ns, T0L 900ns. Hence, by default, these
• are chosen to be conservative and avoid problems rather than for maximum throughput; in the code,
• this is done by default using a WS2812_TIMING parameter that accounts for the whole window (1250ns)
• and defining T1H and T0H; T1L and T0L are obtained by subtracting their low counterparts from the window.
• However, there are certain "WS2812"-like LEDs, like the SK6812s, which work in a similar
• communication topology but use different timings for the window and the T1L, T1H, T0L and T0H.
• This means that, albeit the same driver being applicable, the timings must be adapted.
  */

#ifndef WS2812_TIMING

define WS2812_TIMING 1250

#endif

#ifndef WS2812_T1H

define WS2812_T1H 900 // Width of a 1 bit in ns

#endif

#ifndef WS2812_T1L

define WS2812_T1L (WS2812_TIMING - WS2812_T1H) // Width of a 1 bit in ns

#endif

#ifndef WS2812_T0H

define WS2812_T0H 350 // Width of a 0 bit in ns

#endif

#ifndef WS2812_T0L

define WS2812_T0L (WS2812_TIMING - WS2812_T0H) // Width of a 0 bit in ns

#endif

I didn't get a chance to give it a try at that time, but recently I reflashed the board with qmk 0.31 and it seems this issue goes away. I will close it for now, thank you!