lemmingDev
setVid and setPid seems to be broken since NimBLE-Arduino 1.4.2
Something changed on NimBLE-Arduino on version 1.4.2,
bleGamepadConfig.setVid(0xe502); bleGamepadConfig.setPid(0xabcd);
Doesn't work any longer. No matter what its the same value VID=0x02e5, PID=0xcdab even if set to the above or anything else....
when i downgrade to NimBLE-Arduino 1.4.1 this works again.
Could this possibly be linked to this upstream issue?. The old behaviour was that there was some bit-shifting happening to the vid and pid values before they got stored in m_pnpCharacteristic. Looking BleGamepad::begin, I noticed that the high and low bytes for the vid and pid values are getting swapped before being passed to the pnp function call to set pnp values - maybe they values don't need to be swapped anymore?
@microbmen Can confirm that getting rid of the high/low byte flipping that was occuring with the VID, PID and GUID values before they were sent to NimBLE fixed the problem for me. Seems that upstream they removed the need for those bytes to be flipped. Submitted a PR to fix the issue.
Tested by running the CharacteristicsConfiguration example with VID set to 0xe502, PID set to 0xABCD and GUID set to 0x1234.
First I ran the sketch with the old behaviour and the following string was returned in Windows device manager for the Hardware IDs property: BTHLEDevice\{00001812-0000-1000-8000-00805f9b34fb}_Dev_VID&0102e5_PID&cdab_REV&3412
As you can see, the VID (ignoring first 01 byte), PID and REV properties have their first and second bytes flipped.
Then I re-ran the sketch with the fix applied that removes the VID, PID and GUID high/low bytes reversal and received the following: BTHLEDevice\{00001812-0000-1000-8000-00805f9b34fb}_Dev_VID&01e502_PID&abcd_REV&1234 which matches the provided PID, VID and GUID values.
I also tested this fix over in my EPS32-BLE-CompositeHID fork with my Xbox controller sketch. The VID and PID are vital for convincing Windows to load the correct Bluetooth LE XINPUT compatible input device driver and without the fix, Windows saw my board as a generic gamepad but with the fix, it started working again.
