Qukeys workaround for bluetooth adapter?

Programming Kaleidoscope Internals
,
1

TL;DR - Handheld Scientific says their bluetooth adapter doesn’t support QMK tap/hold functionality out of the box, and they suggest setting a bigger delay between key press and key release events; how would I do this with Kaleidoscope.Qukeys and the Keyboardio Model 01?

Background:

There have been considerations for a Bluetooth model of the Keyboardio, but naturally I’m impatient. Luckily, we have a solution that works through Handheld Scientific’s Bluetooth Adapter.

There’s a problem, though: support for Qukeys functionality like tap/hold configurations is lacking. See the “QMK based keyboards” for those details.

Possible Solution:

A very helpful person noted how to fix this in an Ergodox context: set a larger delay between key press and key release events, and they suggest 10 milliseconds.

How would I configure Kaleidoscope.Qukeys to do this? I had originally thought setReleaseDelay() was a possible solution, but the upgrade docs clarify the actual intent of this deprecated function. I also don’t see an obvious solution in the Qukeys configuration docs. If configuration isn’t an option, what does a workaround look like for the Keyboardio Model 01?

Attaching firmware ISO in case it’s needed:

Model01-Firmware.ino (15.2 KB)

2

Sorry for taking so long to reply; I haven’t been keeping up lately.

It seems to me that this problem would not be isolated to Qukeys, but would also apply to lots of other stuff, too, where reports are sent to the host in rapid succession (e.g. keys with modifiers added). This would be best addressed in Kaleidoscope itself, rather than in a plugin. The best way to do it would probably be for Kaleidoscope to track the timestamp of the previous report that was sent, and delay a report if it’s coming too soon. Probably the best place to put this would be in KeyboardioHID.

My initial reaction to this idea is that I wouldn’t want this code added to the main codeline of Kaleidoscope. Any delays like that could result in hardware event going undetected, especially with very long delays (10ms is a lot of time!). I would be willing to help you figure out how to add that code to KeyboardioHID yourself, if you’re interested.

1 Like
3

I would love any advice you have to offer, thank you so much. I’m particularly interested in how to modify KaleidoscopeHID locally and what to look for when testing.

I’m on vacation this week, but if you have any tips to share asynchronously, please feel free.

4

What I would try is replacing the code here:

…with something like this:

int Keyboard_::sendReportUnchecked() {
  static constexpr uint8_t min_report_interval = 10;
  static uint32_t last_report_time = 0;
  uint32_t current_time = millis();
  uint32_t elapsed_time = current_time - last_report_time;
  if (elapsed_time < min_report_interval) {
    delay(min_report_interval - elapsed_time);
  }
  last_report_time = millis();
  return HID().SendReport(HID_REPORTID_NKRO_KEYBOARD,
                          &last_report_, sizeof(last_report_));
}

I haven’t tested this, so I may have made an error, but this ought to be the simplest way to guarantee a minimum interval between keyboard HID reports. I would not recommend using such a large interval unless a smaller one doesn’t work.

1 Like
5

This is way below the level of this thread, but was hoping to engage this brain trust!

I just got the BT500 adapter from Handheld Scientific and it isn’t registering any keypresses from my Keyboardio Atreus, Model 100, or Epomaker numpad.

It is working when using a generic Logitech wireless keyboard and a Periloot Caravel gaming board so I’m assuming its not a defective unit.

Any advice on how to get it to register keypresses? My Keyboardio keyboards have no mods and I’m using them with the Chrysalis software. Handheld Scientific hasn’t gotten back when I’ve reached out to them :frowning: Thanks much!