AT+BLEHIDKB behaviour is not the same as USB HID

[dairequinlan]

Environment

• Development Kit: ESP32-DevKitC
• Module or chip used: ESP32-WROOM-32
• ESP32-AT Release v2.2.0.0
• Operating System: Linux
• Power Supply: external 3.3V

Problem Description

Using the built in BLEHID functionality, specifically the AT+BLEHIDKB command, sending a single BLEHIDKB command results in a keypress and release on the paired device. i.e.

AT+BLEHIDKB=0,4,0,0,0,0,0 will result in 'a' being input

As per normal HID usage, sending the above should result in a single key press event on the device, and then a subsequent command of something like

AT+BLEHIDKB=0,0,0,0,0,0,0

should result in a key 'release' event. This is how the USB HID reports work.

Expected Behavior

sending AT+BLEHIDKB=0,4,0,0,0,0,0 should result in 'a' being input, then after a short delay, 'aaaaaaaaaaaaaaaaaaa' until a subsequent BLEHIDKB command is sent to clear the input.

Actual Behavior

sending AT+BLEHIDKB=0,4,0,0,0,0,0 seems to send the equivalent of a key press followed by a key release.

Steps to repropduce

1. send AT+BLEHIDKB=0,4,0,0,0,0,0 to a paired device, a single 'a' will be input.

Code to reproduce this issue

Any code which sends that BLEHIDKB command should reproduce the issue, it's a problem in the behaviour of the built in HID functionality.

[ustccw]

@xiewenxiang PTAL

[Luxin812]

I think for "send AT+BLEHIDKB=0,4,0,0,0,0,0 should result in input 'a', then after a short delay, 'aaaaaaaaaaaaaaaaaaaa'" this behavior should be implemented on the MCU side, eg input How many 'a', how many times the MCU control command is input.

[dairequinlan]

@Luxin812 no, that's not the behaviour of USB HID at least, and BLE HID seems to work identically. The delay is set on the client machine, say 200 ms or whatever, and the command behaviour is as I outline above i.e. the client machine receives a HID Keyboard report with a specific code in one of those slots (6 by default) which results in it outputting that character, then after the configured delay, repeating that same character. It will do this until it receives a key report that DOESN'T have that keycode in it (i.e. a 'key up') or a key report with an additional different key (i.e. another key was pressed). All that repetition behaviour is handled on the client, not on the HID device.

[jeremyherbert]

@ustccw i have observed the same problem and agree with @dairequinlan - the current behaviour is not how the HID report is supposed to work. Keyboard keys (as defined in USB HID section 10) are “Selectors” as per USB HID spec 3.4.2.1, as such the report contains the set of keys that are currently being pressed. When you want to release a key, you provide a report (a set) which doesn’t contain the key code. Pressing and releasing a key requires two separate reports to be sent.