This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to implement Ctrl-C for HID keyboard

Hi Guys, I try to implements the ctrl-C/V for bluetooth HID keyboard. But from SDK, I can't figure out how to send two keys. Even I do not use buffer_enqueue/dequeue in order to keep 'Ctrl' pressed, not released, still can't work. Does anyone figure out how to work on it?

Parents
  • I have no clue how the SDK for HID or HID on bluetooth work, but in case it can help, on a regular keyboard you have "make" and "break" codes. You would send a "Ctrl" make (press) then a "C" make, then C break (release) and Ctrl break.

    From what I remember on USB HID (just checked 5-10 years old code), I'd get reports of X bytes, where X is the maximum amount of key presses keyboard would handle. In your case, let's imagine you support 8 keys, you'd first send a report (sorry, that's USB HID terminology, I don't know if they use the same in Bluetooth HID, take it as "packet" otherwise) with first byte indicating Ctrl, then 7 bytes to 0. Then a report with 1st byte indicating Ctrl, 2nd one indicating "C", then 6 bytes to 0. Then back to Ctrl in 1st byte and 7x 0 bytes, then a report with 8x 0 (not necessary, most OSes will only require C to be released to perform action, but nice to be clean and not have "ghost" keys).

    Hope that helps!

Reply
  • I have no clue how the SDK for HID or HID on bluetooth work, but in case it can help, on a regular keyboard you have "make" and "break" codes. You would send a "Ctrl" make (press) then a "C" make, then C break (release) and Ctrl break.

    From what I remember on USB HID (just checked 5-10 years old code), I'd get reports of X bytes, where X is the maximum amount of key presses keyboard would handle. In your case, let's imagine you support 8 keys, you'd first send a report (sorry, that's USB HID terminology, I don't know if they use the same in Bluetooth HID, take it as "packet" otherwise) with first byte indicating Ctrl, then 7 bytes to 0. Then a report with 1st byte indicating Ctrl, 2nd one indicating "C", then 6 bytes to 0. Then back to Ctrl in 1st byte and 7x 0 bytes, then a report with 8x 0 (not necessary, most OSes will only require C to be released to perform action, but nice to be clean and not have "ghost" keys).

    Hope that helps!

Children
Related