[Request for insight] Android set_player_leds info?

[LeeNX]

Is your feature request related to a problem? Please describe.
Looking for info or insight on how the android_set_player_leds is enabled? Basically looking to find out what would be needed to add to the Gatt Descriptor to work with bluepad32.

I was thinking something like:

// ------------------------------------------------- Player 1 to 4 leds
  REPORT_COUNT(1),     0x04,          //   REPORT_COUNT (4) ; 4 bits (Player 1, Player 2, Player 3, Player 4)
  REPORT_SIZE(1),      0x01,          //   REPORT_SIZE (1)
  USAGE_PAGE(1),       0x08,          //   USAGE_PAGE (LEDs)
  USAGE_MINIMUM(1),    0x61,          //   USAGE_MINIMUM (0x61) ; Player 1
  USAGE_MAXIMUM(1),    0x64,          //   USAGE_MAXIMUM (0x64) ; Player 4
  HIDOUTPUT(1),        0x02,          //   OUTPUT (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
  REPORT_COUNT(1),     0x01,          //   REPORT_COUNT (1) ; 4 bits (Padding)
  REPORT_SIZE(1),      0x04,          //   REPORT_SIZE (4)
  HIDOUTPUT(1),        0x01,          //   OUTPUT (Const,Array,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)

Been looking for an implementation that I could use or mimic so that I could add to the ESP32-BLE-Gamepad library, but not yet found anything that I can use, might just be a poor programming skills.

I found the function uni_hid_parser_android_set_player_leds in uni_hid_parser_android.c, but I can't see how it's enabled.

[ricardoquesada]

yes, uni_hid_parser_android_set_player_leds() is disabled because I couldn't make it work in any Android controller.

You can try to enable it by changing the #if 0 to #if 1 here: https://github.com/ricardoquesada/bluepad32/blob/main/src/components/bluepad32/parser/uni_hid_parser_android.c#L222

and then try setting the correct report_id... but that will only work with BR/EDR controllers.

For BLE controllers you will need to change that with something like hids_client_send_write_report(...).

Search in the Bluepad32 for hids_client_send_write_report to see how it is being used by the other BLE drivers

[LeeNX]

Thanks @ricardoquesada, for your time, insight and understanding.

I did think that function was disabled, but normally see a debug env or something. Again, apologies for my poor coding skills.

I will investigate hids_client_send_write_report. In my testings for HID report writing, I was able to get my PoC accepting and acting on a HID report, but have not been able to get any service to register GATT service to a function.

Maybe nobody has made a device that is a good reference design via BLE only? I was hoping that if the correct Gatt Descriptor was in place, it would just be picked up, but my research has shown that software like SDL are tied to VID:PID associated implementations, like XInput for XBox and Playstation devices.

If you see or know of anything that is worth sharing, please let me know.

[ricardoquesada]

I think you are in the right direction, but I got confused with the terminology.

What you need to do, is to define an "Input report" in the "HID descriptor".

I guess, just a guess, that on the gamepad then you should receive a sort of "Gatt service hid report" event.

That's my guess.

[LeeNX]

Thanks @ricardoquesada for your input, no pun intended ;-) That might have been more funny in my head.

I might have abuse the terminology trying to sound like I know what I am doing, but I am just guessing.

I think the input report is the standard why the HID is setup for buttons, I think it's an output which will create report means as an example:
from https://github.com/lemmingDev/ESP32-BLE-Gamepad/blob/11ee6e927df7c8bef37b2cdc36eb798e5173c15f/BleGamepad.cpp#L426

        // INPUT (Data,Var,Abs)
        tempHidReportDescriptor[hidReportDescriptorSize++] = 0x81;
        tempHidReportDescriptor[hidReportDescriptorSize++] = 0x02;

or https://github.com/DJm00n/ControllersInfo/blob/82c1d04494df9886b0f35f77e2435b5e3938575b/stadiacontroller/stadiacontroller_bluetoothle_hid_report_descriptor.txt#L107

85 05          (GLOBAL) REPORT_ID          0x05 (5)  
06 0F00        (GLOBAL) USAGE_PAGE         0x000F Physical Interface Device Page 
09 97          (LOCAL)  USAGE              0x000F0097 DC Enable Actuators (Selector)  
75 10          (GLOBAL) REPORT_SIZE        0x10 (16) Number of bits per field  
95 02          (GLOBAL) REPORT_COUNT       0x02 (2) Number of fields  
27 FFFF0000    (GLOBAL) LOGICAL_MAXIMUM    0x0000FFFF (65535)  
91 02          (MAIN)   OUTPUT             0x00000002 (2 fields x 16 bits) 0=Data 1=Variable 0=Absolute 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap  <-- Error: PHYSICAL_MINIMUM is undefined
C0           (MAIN)   END_COLLECTION     Application 

thou you may be looking at it from the host view vs where I am been looking at it from the device view.

Rather let me update my PoC and make a build with some tests and see where we get.

Mind if I poke you further? Have not found anywhere else that has offered feedback.

Thanks a ton.

Two things that I don't understand or can track in the code, is how does the HID descriptor is parsed and then used to expose the feature set of the gamepad/device connected.

[ricardoquesada]

a bit late but...

the "hid descriptor" is sent from the gamepad to the host.
the host uses the "hid descriptor" to know the meaning of each byte: first byte is a button, 2nd byte is the dpad, etc...

the gampead, AFAIK, has no real need for the HID Descriptor, besides reporting it to the host.

I'm closing this bug.

Please, reopen if you still have questions

[LeeNX]

Thanks @ricardoquesada. Please can we keep this open? I am still interested in getting this working or outlining why it might not currently be possible, but I am hoping it is.

I was trying to understand how the HID descriptor is parsed, so that I can see where in Bluepad32 might setup LED incoming hook? If that is the correct terminology.

I am not sure what characteristic need to be defined in the HID descriptor on the client, so that Bluepad32 can find and setup LED functions. I was thinking it might be similar to how BLE keyboards do their LEDs, but I see there is an issue open about how to handle these. Might it be worth setting a sketch to help debug that? In the HID descriptor reported, is the Report ID not also noted? I remember seeing info about gamepads needing or using Report IDs other than the first one, but should be found in the HID descriptor.

I was also wonder how Bluepad32 selects device category, I was initially guessing the VID:PID of client device, but have not confirmed myself, could I ask if I am right or if Bluepad32 is doing some sort of HID descriptor pattern patching or something?

[ricardoquesada]

Bluepad32 parses the HID here:

bluepad32/src/components/bluepad32/parser/uni_hid_parser.c

Line 23 in 6efa712

void uni_hid_parse_input_report(struct uni_hid_device_s* d, const uint8_t* report, uint16_t report_len) {

yes, VID:PID are the primary values used to determine the type of device.

[ricardoquesada]

I'm reopening the issue, but I don't understand what exactly is the problem and/or question. Can you describe what exactly you need from Bluepad32 ?

[LeeNX]

Thanks @ricardoquesada

I would like to add PlayerLED(s) support to ESP32-BLE-Gamepad and hopefully have Bluepad32 support this, which I was thinking might be easy and a stepping stone to rumble and possible haptic.

Seeing that ESP32-BLE-Gamepad v0.6.x now has Output Report ID, thinking things might be aligning, but my limited programming skills slowing things down. With this been a small set of people that might be interested, I did not think a feature request would make much progress.