HID over GATT USB Translation compatibility

[Deflation8257]

Hi there,

I'm trying to implement section 4.8.1, "Translation Layer" of the HID over GATT Profile 1.0 specification: https://www.bluetooth.com/specifications/specs/hid-over-gatt-profile-1-0/

As far as I can tell, it boils down to "use discovery to get the report descriptors, feed them into the USB HID class, subscribe to report events, pip those into the USB HID class too".

However from what I can see, the nrf52 SDK mostly uses C macros for the descriptors and the macros (like APP_USBD_HID_GENERIC_GLOBAL_DEF_INTERNAL) seem to make liberal use of static storage.

Is the nrf52 SDK basically just incompatible with this use-case?

[Edvin]

Hello,

Sorry, but I am not sure I understand exactly what you are trying to do. You refer to HID over BLE, right? But the APP_USBD_HID_GENERIC_GLOBAL_DEF_INTERNAL seems like a USB HID macro.

If you intend to have HID over BLE, then you shouldn't use the USB at all. 

Perhaps I misunderstood what you are trying to do. Perhaps you can explain a bit more about what you are trying to achieve.

Best regards,

Edvin

[Deflation8257]

I want to have the nRF52 act as a USB HID device. Rather than take input from an optical sensor or key presses, the nRF52 should act as a BLE central to connect to a BLE HID peripheral. The HID report map from the BLE peripheral should be used as the USB HID report descriptor. The HID reports from the BLE peripheral should be used as USB HID reports.

That is, the nRF52 should proxy BLE HID to USB so that a HID can function even on a device that isn't compatible with HCI (such as a PC BIOS).

[Edvin]

Ok, I understand. What SDK are you using? I assume you are using the nRF5 SDK, since you mention the APP_USBD_HID_GENERIC_GLOBAL_DEF_INTERNAL. Let me know if this is not the case.

So what you are asking for is not something that we have out of the box. I guess the ubsd_hid_composite will work as a USB keyboard, and then you need to receive the HID over BLE from a BLE peripheral that will act as the keyboard. 

We do have an example that you can use for the peripheral, the SDK\examples\ble_peripheral\ble_app_hids_keyboard, but we do not have any ble_central examples that works with the HID peripherals. That is something that you would have to implement yourself. We have a couple of other central examples found in SDK\examples\ble_central, that you can look at for general BLE centrals. 

Luckily, the HID over BLE is not too complex. It just sends the HID table whenever there is a button/key press. So what you would need to do is to just forward this table to the physical USB, instead of triggering the USB events from the button presses on the DK.

Best regards,

Edvin

[Turbo J]

That will be a nightmare to use and implement.

Windows caches the report descriptor in the registry, so it won't react to connecting a different HID peripherial properly.

You also need to delay the USB connect until you have read the report descriptor from the BTLE device or have a cached version on the nrf52 available somehow.

This will need significant changes to the USB stack in either SDK version, as IIRC both assume static HID report descriptors and endpoint size.

Remember that you also need a different endpoint size that corresponds to the report descriptor. That means you would need to parse it on the NRF52, which is a non-trivial task.