Hi,
USB HID usage table for Consumer Devices (pg.12 = 0x0C), eg:
0x01 : Consumer Control
0x02 : Numeric Keypad
0x30 : Power
0x40 : Menu
0xE2 : Mute
0xE9 : Volume Up
0xEA : Volume Down
0x221 : AC Search
0x223 : AC Home
etc.
In the BLE stack v1.4.0 source code (‘hidAdvRemote’ sample code), all the HID_CONSUMER_xxxxx (defined in hiddev.h) supported in BLE stack is single-Byte code (1byte code).
eg: #define HID_CONSUMER_POWER 48 // 0x30 - Power
#define HID_CONSUMER_MENU 64 // 0x40 - Menu
#define HID_CONSUMER_MUTE 226 // 0xE2 - Mute
#define HID_CONSUMER_VOLUME_UP 233 // 0xE9 - Volume Increment
#define HID_CONSUMER_VOLUME_DOWN 234 // 0xEA - Volume Decrement
The way it’s declared in the keycodeMap_t keycodeMap[] table is also based on 1byte code array.
// Keycode mapping table
typedef struct
{
uint8 keycode;
uint8 usagePage;
} keycodeMap_t;
However, it’s converted into 2bytes buffer ‘pBuf[1:0] (below table) by ‘hidCCBuildReport()’ in ‘hidCCSendReport()’ routine, before the report data is sent out. These 2bytes code are totally different with the HID Consumer Control codes (above).
Debugging the ‘HIDAdvRemoteDongle’, found that the Dongle indeed receive the pBuf[1:0] values below (not the HID Consumer Control code/values).
Key |
keycode |
HID_CC_RPT_SET_xxxxxx (s, x) |
pBuf[1:0] |
HID_CONSUMER_CHANNEL_UP |
0x9C |
(s)[0] &= HID_CC_RPT_CHANNEL_BITS; \ |
0x00,0x10 |
HID_CONSUMER_CHANNEL_DOWN |
0x9D |
(s)[0] &= HID_CC_RPT_CHANNEL_BITS; \ |
0x00,0x30 |
HID_CONSUMER_VOLUME_UP |
0xE9 |
(s)[0] &= HID_CC_RPT_VOLUME_BITS; \ |
0x00,0x40 |
HID_CONSUMER_VOLUME_DOWN |
0xEA |
(s)[0] &= HID_CC_RPT_VOLUME_BITS; \ |
0x00,0x80 |
HID_CONSUMER_MUTE |
0xE2 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x01,0x00 |
HID_CONSUMER_POWER |
0x30 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x02,0x00 |
HID_CONSUMER_RECALL_LAST |
0x83 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x03,0x00 |
HID_CONSUMER_ASSIGN_SEL |
0x81 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x04,0x00 |
HID_CONSUMER_PLAY |
0xB0 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x05,0x00 |
HID_CONSUMER_PAUSE |
0xB1 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x06,0x00 |
HID_CONSUMER_RECORD |
0xB2 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x07,0x00 |
HID_CONSUMER_FAST_FORWARD |
0xB3 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x08,0x00 |
HID_CONSUMER_REWIND |
0xB4 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x09,0x00 |
HID_CONSUMER_SCAN_NEXT_TRK |
0xB5 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x0A,0x00 |
HID_CONSUMER_SCAN_PREV_TRK |
0xB6 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x0B,0x00 |
HID_CONSUMER_STOP |
0xB7 |
(s)[1] &= HID_CC_RPT_BUTTON_BITS; \ |
0x0C,0x00 |
[Q1]: After checking with the ‘entity1Desc’ (Consumer report descriptor in ‘usb_hid_descriptor.s51’), is it correct that the data format follow the following format ?
pBuf[1] |
pBuf[0] |
||||||||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not used (reserved) |
selection |
Buttons: (Mute / Power / … / Stop / etc). |
vol. down |
vol. up |
chnl. up/dn |
numeric keys |
[Q2]: the above data format shows that the consumer report descriptor does not support 2bytes consumer control code (eg: 0x221 = AC Search, or 0x223 = AC Home, etc).
Does TI BLE stack (incl. Audio version) supports 2bytes HID Consumer Control code ? How / what values should be declared in the report descriptor ?
If not supported, how to handle the 2bytes HID Consumer Control key code ?
Thank you in advance.