The default debounce algorithm in QMK also introduces a minimum of 5ms delay, and the default usb polling rate another 10ms.
To mitigate the debounce algorithm delay, you can put "DEBOUNCE_TYPE = asym_eager_defer_pk" in your rules.mk file.
What this does:
asym: use different debounce algorithm for key-down and key-up events.
eager: the key-down is registered instantly at the first signal, instead of waiting 5ms for debounce
defer: registering key-up will wait for the debounce delay, this will make sure you won't get multiple key-downs registered before a proper key-up
pk: per key debounce timer, uses the most resource but you have plenty on your rp2040. although I don't completely understand how this works, this is supposed to be the fastest.
To increase the polling rate, this can be defined in config.h:
#define USB_POLLING_INTERVAL_MS 2
It's in ms, so 2 is 500hz, 1 is 1000hz, IMO the latter is overkill.
Together, you save a minimum of 6ms, maximum of 14ms of delay, which is orders of magnitude more than you save by not scanning the matrix.
To mitigate the debounce algorithm delay, you can put "DEBOUNCE_TYPE = asym_eager_defer_pk" in your rules.mk file.
What this does:
asym: use different debounce algorithm for key-down and key-up events.
eager: the key-down is registered instantly at the first signal, instead of waiting 5ms for debounce
defer: registering key-up will wait for the debounce delay, this will make sure you won't get multiple key-downs registered before a proper key-up
pk: per key debounce timer, uses the most resource but you have plenty on your rp2040. although I don't completely understand how this works, this is supposed to be the fastest.
To increase the polling rate, this can be defined in config.h:
#define USB_POLLING_INTERVAL_MS 2
It's in ms, so 2 is 500hz, 1 is 1000hz, IMO the latter is overkill.
Together, you save a minimum of 6ms, maximum of 14ms of delay, which is orders of magnitude more than you save by not scanning the matrix.