How to pass correct hid device name

[SiMachines]

Device does not show up with the ble name given instead windows generates a name.

[SiMachines]

https://www.bluetooth.com/specifications/specs/human-interface-device-profile-1-1-1/
5.3.3 SDP Attribute Summary: Service Name

[SiMachines]

https://github.com/lemmingDev/ESP32-BLE-Gamepad/issues/35

[afpineda]

Same question here.

5.3.3 SDP Attribute Summary: Service Name

I read somewhere else that Windows takes the controller name from that attribute in the advertisment. How to set that? No idea.

To my opinion, we need better API documentation.

[h2zero]

I read somewhere else that Windows takes the controller name from that attribute in the advertisment. How to set that? No idea.

I'm not sure how windows recognizes the device name and as far as HID support is concerned I don't know much about it, the code for it is community supplied.

There are 2 ways to set the name via BLE: NimBLEDevice::init("your device name") or: NimBLEAdvertising::setName("your device name") or NimBLEAdvertisementData::setName("your device name") if using custom data etc...

To my opinion, we need better API documentation.

While this is true for any repo it's not easy to maintain and I welcome with open arms any contributions. I'm not sure what documentation is missing for this use case, can you elaborate?

Here is the way most of this HID stuff works, USB or Bluetooth, there is a VID and PID value, Windows probably looks at those first, compares to the table of registered devices and derives the name from the registry, ignoring any other data from the BLE device, this is only my guess. If I am correct in my suspicion, and windows ignores the values I have described how to set above, then there is nothing you can do unless you want to spend $$$$ to register your VID/PID to have it recognized by windows.

[afpineda]

I'm not sure how windows recognizes the device name and as far as HID support is concerned I don't know much about it, the code for it is community supplied.

There is no issue with the device name. It is correctly set by NimBLE and correctly recognized by Windows. The point is this: The HID "controller name" is not the same as the "device name". This fact is causing some confusion.

There are 2 ways to set the name via BLE: NimBLEDevice::init("your device name") or: NimBLEAdvertising::setName("your device name") or NimBLEAdvertisementData::setName("your device name") if using custom data etc...

I did some tests. NimBLEAdvertising::setName() does not solve the issue because the issue is not related to the device name, but to the service name (see below), I guess.

Here is the way most of this HID stuff works, USB or Bluetooth, there is a VID and PID value, Windows probably looks at those first, compares to the table of registered devices and derives the name from the registry, ignoring any other data from the BLE device, this is only my guess. If I am correct in my suspicion, and windows ignores the values I have described how to set above, then there is nothing you can do unless you want to spend $$$$ to register your VID/PID to have it recognized by windows.

This question has been answered by a Microsot's employee here: https://learn.microsoft.com/en-us/answers/questions/406840/hidd-getproductstring-with-classic-bluetooth-devic

"The product string returned will be the value of the SDP attribute called "Service Name" in table 5.3 (section 5.3.3) of the spec."

I took a look to that section, which is available here: https://www.bluetooth.com/specifications/specs/human-interface-device-profile-1-1-1/ It states that the SDP attribute "Service Name" is optional. So, I guess it is not implemented in NimBLE by default. I would like to add such attribute myself, but how?

[h2zero]

Thanks, that makes sense. I don't know much about the HID stuff, never had to work with it.

I'd suggest looking at how all the other attributes are added and see if you can add this one and the same manner.

[afpineda]

I took a look to that section, which is available here: https://www.bluetooth.com/specifications/specs/human-interface-device-profile-1-1-1/ It states that the SDP attribute "Service Name" is optional. So, I guess it is not implemented in NimBLE by default. I would like to add such attribute myself, but how?

My mistake. This applies to Bluetooth classic only, not BLE.

However, I found a proper workaround, which is described here.

[h2zero]

Thanks for the update, confirms my suspicions that windows gets the name from the Bluetooth registry using the VID/PID which isn't home gamer friendly obviously.

[Volanaro]

Im having the same Problem, dose this mean its not possible? or can someone make some sort of guide :3?

[h2zero]

@Volanaro The only way that we know of at this time is to manually change the name in the Windows registry as there is no provision in the BLE HID spec to provide the product name.

[Volanaro]

ahh okay thanks!, wonding if it would be possible to spoof the bluetooth as usb... dout it.. that would be another problem initself lol

[afpineda]

An excerpt from the link above:

Why all this mess?

Believe it or not, the HID specification does not include a "display name". Windows figures out what to show in this manner:

• USB: the display name is taken from the "product string", which is a certain USB string descriptor.

• Bluetooth classic: the display name is taken from the value of the SDP attribute called "Service Name". See table 5.3 (section 5.3.3) from the Bluetooth HID specification.

• BLE: according to the HID over GATT specification there is nowhere to get a display name. When a device is advertised, Windows ought to take note of the device name, but it doesn't. The open-source community is still in the dark about how commercial products show a custom display name.

ahh okay thanks!, wonding if it would be possible to spoof the bluetooth as usb... dout it.. that would be another problem initself lol

In fact, you can. You may assign the same VID/PID found in a USB device to a BLE device because VID/PID does not play a role in the loading of the drivers for a BLE device.

However, never do the opposite.

[h2zero]

Closing this as it is not an issue with this library.