Repository: HaoboGu/rmk (language: rust)

Issue:
Slight delay in registering a keystroke after 5-6 keystrokes
I'm experiencing a slight delay in registering a keystroke after 5-6 keystrokes. Even if you keep holding it's still the same after like 500ms of holding there's a hiccup in registering the next keystroke.

checked out commit: `c72bcd353f1cd462043c87e3db921f1dd0ef51b`
firmware: `examples/use_rust/nrf52840_ble_split`


Discussion / hints:
the delay happens even if you press only one key and hold it?
I cannot repro this issue. If you're holding one key and experiencing lag, that might not be related to RMK since RMK only sends one report when you press the key, and another when you release.
Hiccups happen either way.

When I hold the key and when I press key successively.

Is there a way to debug and send you the debug report?
Could you record your screen? with both RMK keyboard and any other keyboard? I still suspect it's not a RMK issue. Holding a key doesn't send key strokes actually 🤔

You can also try the USB mode to see whether it happens? I have no idea now...
Building a split keyboard also has delays, but those using the ZMK firmware do not experience this issue.
> Building a split keyboard also has delays, but those using the ZMK firmware do not experience this issue.

Could you provide more information about it? What MCU/rmk version/connection type do you use? And what kind of delay are you experiencing?
> > Building a split keyboard also has delays, but those using the ZMK firmware do not experience this issue.
> 
> Could you provide more information about it? What MCU/rmk version/connection type do you use? And what kind of delay are you experiencing?

hardware & firmware from https://github.com/HaoboGu/rmk/issues/166


https://github.com/user-attachments/assets/3e63f1a6-1de9-478d-af52-e3d7e5475db2



> > > Building a split keyboard also has delays, but those using the ZMK firmware do not experience this issue.
> > 
> > 
> > Could you provide more information about it? What MCU/rmk version/connection type do you use? And what kind of delay are you experiencing?
> 
> hardware & firmware from #166
> 
>  1_1733240630.mp4

@HaoboGu help~
@jsenjobs Could you try `fix/lag` branch?


> @jsenjobs Could you try `fix/lag` branch?


https://github.com/user-attachments/assets/4c9daa3f-9dfe-4a1a-9161-19dd35a6430c

It seems that another issue [keymap not effected #166](https://github.com/HaoboGu/rmk/issues/166) has been fixed, but the delay still exists.

Hallo, I think I might have found the cause of this to be use of `sd_ble_gap_conn_param_update` [on the peripheral](https://github.com/HaoboGu/rmk/blob/a212bbba6d328d6fa311bd77a9b90768ec7764b9/rmk/src/split/peripheral.rs#L263).
For some reason using it causes the connection between the peripheral and central on my keyboard to drop, however it's barely noticeable outside of a missing keypress as the connection is remade pretty quickly.

Unfortunately I don't know why/ how asking for a connection param change causes the connection drop...
> Hallo, I think I might have found the cause of this to be use of `sd_ble_gap_conn_param_update` [on the peripheral](https://github.com/HaoboGu/rmk/blob/a212bbba6d328d6fa311bd77a9b90768ec7764b9/rmk/src/split/peripheral.rs#L263).
> 
> For some reason using it causes the connection between the peripheral and central on my keyboard to drop, however it's barely noticeable outside of a missing keypress as the connection is remade pretty quickly.
> 
> 
> 
> Unfortunately I don't know why/ how asking for a connection param change causes the connection drop...

funny, I haven't think about it! Actually this function is used to reduce the latency. I'll look into it today. Thanks very much for the report!

Fix patch:
diff --git a/rmk/src/ble/nrf/mod.rs b/rmk/src/ble/nrf/mod.rs
index 966cd122..9e35ab4a 100644
--- a/rmk/src/ble/nrf/mod.rs
+++ b/rmk/src/ble/nrf/mod.rs
@@ -490,7 +490,7 @@ pub(crate) async fn set_conn_params(conn: &Connection) {
             );
             debug!("Set conn params result: {:?}", re);
 
-            embassy_time::Timer::after_millis(50).await;
+            embassy_time::Timer::after_millis(5000).await;
 
             // Setting the conn param the second time ensures that we have best performance on all platforms
             let re = sd_ble_gap_conn_param_update(


Test patch: