-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KeyboardBLE+MouseBLE+JoystickBLE #1506
Comments
I'm not a Bluetooth expert, so take this with a grain of salt, but right now this is because the BTstack GATT/HID handler is hardcoded to only support a single descriptor and report back. In plain USB you can have one HID endpoint with multiple reports, which is how we do Mouse+KBD+joystick. Concatenate all 3 descriptors when setting up, and then send back each report with a unique ID associated w/each separate desriptor. Not sure if the HID emulation in BLE supports this. If it does, then you'd need to handle concatenation of the HID descriptors (see the If the BLE HID service doesn't support multiple desriptors and reports, then I suppose you'd need to expose separate services for each one and then updaet the hids_device to support this. What would help is if you had a multi-HID function BLE device to check out. That way you could see how those multiple HIDs are exposed. I only seem to have BLE mice and nothing else, so can't offer any suggestions. |
As you can see there, the ATT service consists of Boot mode mouse & keyboard and Report mode (in & out). AFAIK merging the 3 report descriptors with appropriate report IDs should work here as well, I've done this successfully for the ESP32: https://github.com/asterics/esp32_mouse_keyboard Would you recommend to create a MouseKeyboardJoystickBLE library, which concatenates the report descriptors from TinyUSB and provides all 3 interfaces? |
That would be great. I'm not sure how to orchestrate it given they will all start at different times, but it would be very nice if we could only expose the included HID devices (i.e. if you |
I'll try to figure something out. In TinyUSB it was quite easy with the weak handler:
Anyway, AFAIK the consumer keys of the Keyboard need a report id as well, so this implementation would allow media keys as well. |
I think the same weak stuff (with a different naming convention ex. "__BLEInstallJoystick") can be used (not sure header guards will be usable...they're only defined on a per compilation unit basis so your .cpp won't know what the main.ino is including). |
Dear @earlephilhower , during development, I ran into a few issues:
I've changed all the necessary stuff here, if I'm finished I will open a PR: |
I just took a quick look at the code. Looks nice and clean! When you're ready, throw a PR this way and we'll see about getting it into the next release. Are you saying, though, that it needs a new BTStack version? That may be a problem as I'm really trying not to modify the PicoSDK upstream. But I didn't see an updated sdk For the libpico docs, I did kind of document it in the tools/README.md where it lives. I guess it's not obvious, though. Not generally needed, thankfully. For BTStack debug, I think they use |
Dear @earlephilhower, unfortunately, the function This function is needed to have a variable count of reports transmitted to the host. I personally don't know why (it seems so unnecessary complicated) every report ID needs its own GATT characteristic. There is already a report characteristic and like in USB it should be possible to determine via the report map (also an extra characteristic) how to handle incoming data. So if you want to try:
Regarding the upstream: I would wait until this change in BTStack is merged in their release & then request an update at the pico-sdk repo. And finally update the pico-sdk submodule here :-).
Yeah, you are right, I just wasn't looking enough :-).
I tried that, but nothing happened. (I tried Serial for USB output). I'll try again and write here if I found something. |
Hi! You can |
Really great stuff, @benjaminaigner and I hope it can come in soon. If the BTstack changes take too long to land in the BTStack repo (and then they would need to wait for a PicoSDK update, too) we can probably pull them in to the |
Dear @earlephilhower , Thanks for the hint with SDK overrides. I'll work on the implementation in this core now, hopefully I can finish it this week. |
Hi again :-). I've implemented all necessary changes, but I'm struggling now with adding the new Basically even the header file is not working (types & functions are not available). Do you have a recommendation to use the header from here: in the Either the declarations are not found (when using the unmodified .h file) or there are conflicting declarations (if changing the header guards to a new name). The linker will be interesting as well. Thank you very much |
Assuming that header isn't used elsewhere in the btstack code(if so, you need a rebuild of the libpico stuff and to keep the modified headers sync'd), just use a form like As for the duplicate definitions, you can either remove the compilation unit from the libpico libs (see tools/libpico/Cmakefile) or wrap it using lib/platform_wrap and rename the functions |
Dear all, But currently, I'm changing the BTSTack submodule to the current develop branch and rebuild libpico. I'll try to fit in the BTSTack changes into an override file, to avoid changing pico-sdk, then I'll open a PR 👍 Greetings |
Fixed by #1587 |
Dear @earlephilhower ,
thx for the progress on this BSP the last months!
Regarding the BLE implementation of Keyboard/Mouse/Joystick:
Is there any suggestion how to use all of them together?
The implementation for USB works as expected (Joystick, Keyboard and Mouse together),
but in BLE (I didn't test BT Classic) only one HID device is working.
I'm willing to implement this, but I want your opinion on how to integrate it most seamlessly in the arduino-pico core.
Greetings
The text was updated successfully, but these errors were encountered: