usb_protocol_information
Differences
This shows you the differences between two versions of the page.
|
usb_protocol_information [2007/02/07 21:38] hydra |
usb_protocol_information [2010/05/10 19:05] (current) |
||
|---|---|---|---|
| Line 22: | Line 22: | ||
| Request data is different for each request. | Request data is different for each request. | ||
| + | |||
| + | |||
| + | |||
| ==== Set Device ==== | ==== Set Device ==== | ||
| Line 45: | Line 48: | ||
| </code> | </code> | ||
| - | When the device is in this mode will cause a "Control" device "Key Test" event to be raised when pressing or releasing any key. | + | When the device is in this mode will cause a "Control" device "Key Test" event to be raised when pressing or releasing any key. There is something rather odd about test mode though. If the RED LED is OFF you will receive up to 6 keypresses in the "Key Test" reponse. However, if the RED LED is ON and you press and hold one key and then press and hold another key you'll get a "Key Test" event with no key press information. Thus, you'll never be able to check for more than one key pressed at a time when in "Test" mode and the RED LED is ON. Weird. |
| <code> | <code> | ||
| Line 69: | Line 72: | ||
| </code> | </code> | ||
| - | * Byte 6: unknown, ergodex and ryan's drivers set this to 0x01 before and after sending one or more "Program Keys" requests, if left set at 0x00 the device appears to work as expected. | + | * Byte 6: unknown, ergodex and ryan's drivers set this to 0x01 before and after sending one or more "Program Keys" requests |
| + | |||
| + | If the pad has been previously sent a set device command with this set to 0x01 sending subsequently setting this to 0x00 has no apparent effect. | ||
| + | If it's never set to 0x01 the pad does not seem to send any data back. TODO: investigate more. | ||
| * Byte 7: unknown, ergodex and ryan's drivers set this to 0x01 before and after sending one or more "Program Keys" requests, if left set at 0x00 the device appears to work as expected. | * Byte 7: unknown, ergodex and ryan's drivers set this to 0x01 before and after sending one or more "Program Keys" requests, if left set at 0x00 the device appears to work as expected. | ||
| + | If the pad has been previously sent a set device command with this set to 0x01 sending subsequently setting this to 0x00 has no apparent effect. | ||
| + | If it's never set to 0x01 the pad does not seem to send any data back. TODO: investigate more. | ||
| Examples: | Examples: | ||
| Line 195: | Line 203: | ||
| Fill with 0x00's | Fill with 0x00's | ||
| + | |||
| + | ==== Unknown Command 1 ==== | ||
| + | |||
| + | The Ergodex software sends this command when recording macros. It has the effect of momentarily turning of the red LED. The green LED remains on. The command it sent once a second and the red led blinks off once a second. | ||
| + | |||
| + | __Usage__ | ||
| + | |||
| + | Only seen being sent when the device is in "Test" mode. | ||
| + | |||
| + | __Request Code__ | ||
| + | |||
| + | 0x08 | ||
| + | |||
| + | __Request Data__ | ||
| + | |||
| + | Unknown. | ||
| + | |||
| + | Here's what the ergodex software sends (complete request, including command code). | ||
| + | |||
| + | <code> | ||
| + | 08 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00 | ||
| + | </code> | ||
| ===== Event and Response Data ===== | ===== Event and Response Data ===== | ||
| Line 218: | Line 248: | ||
| This indicates the values are additive, it has been reported it's possible to assign a key to "Modifier Key" and use the value 0x07 which simulates pressing all the keys together. | This indicates the values are additive, it has been reported it's possible to assign a key to "Modifier Key" and use the value 0x07 which simulates pressing all the keys together. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| Line 249: | Line 285: | ||
| * Byte 1: unknown (seen value 0x04 only) | * Byte 1: unknown (seen value 0x04 only) | ||
| - | * Byte 2: status of something (seen values 0x00 and 0x01) - might be of led or whether keys are active? | + | * Byte 2: status of something (seen values 0x00 and 0x01) - whether keys are active? |
| - | * Byte 3: status of something (seen values 0x00 and 0x01) - might be of led or whether keys are active? | + | * Byte 3: status of leds, the bitmask is the same as for the setting LED's using the "Set Device" request |
| * Byte 4: bit-mapped button status. | * Byte 4: bit-mapped button status. | ||
| - | The last two bits indicate the current status of the buttons | + | The first two bits indicate the current status of the buttons |
| 0x00 - 00 - both buttons pressed | 0x00 - 00 - both buttons pressed | ||
| Line 260: | Line 296: | ||
| 0x03 - 11 - no buttons pressed | 0x03 - 11 - no buttons pressed | ||
| - | * Byte 5: status of something (seen values 0x00 and 0x01) - might be of led or whether keys are active? | + | When these two bits are inverted they make up a bitmask of the button status. When inverted the first bit (lsb) is 1 when the hand button is pressed and the second bit is 1 when the record button is pressed. |
| + | |||
| + | example: | ||
| + | <code> | ||
| + | #define PRES_EROGODEXDX1_OFFSET_STATUS_BUTTONS 0x04 | ||
| + | |||
| + | #define PRES_EROGDEXDX1_BITMASK_BUTTON_HAND ( 1 << 0 ) | ||
| + | #define PRES_EROGDEXDX1_BITMASK_BUTTON_RECORD ( 1 << 1 ) | ||
| + | |||
| + | BOOL bRecordButtonPressed = !(*(pResponseData + PRES_EROGODEXDX1_OFFSET_STATUS_BUTTONS) & PRES_EROGDEXDX1_BITMASK_BUTTON_RECORD); | ||
| + | BOOL bHandButtonPressed = !(*(pResponseData + PRES_EROGODEXDX1_OFFSET_STATUS_BUTTONS) & PRES_EROGDEXDX1_BITMASK_BUTTON_HAND); | ||
| + | </code> | ||
| + | |||
| + | * Byte 5: keymap status | ||
| It looks like byte 5 is set as follows: | It looks like byte 5 is set as follows: | ||
| 0x01 - keys are enabled | 0x01 - keys are enabled | ||
| - | 0x00 - keys are enabled | + | 0x00 - keys are disabled |
| - | + | ||
| - | TODO: verify this | + | |
| * Bytes 6-15: unknown (only seen filled with 0x00's) | * Bytes 6-15: unknown (only seen filled with 0x00's) | ||
| Line 288: | Line 335: | ||
| * Bytes 3-8: | * Bytes 3-8: | ||
| - | when a key is pressed the values corresponds to number printed on the physical keys | + | When a key is pressed the values corresponds to number printed on the physical keys |
| + | |||
| + | If one key is pressed then byte 3 will be the number of the key pressed, bytes 4-8 will contain 0x00 | ||
| - | if one key is pressed then byte 3 will be the number of the key pressed, bytes 4-8 will contain 0x00 | + | If two keys are pressed then byte 3 and 4 will contain the numbers of the key that are currently pressed in random order, bytes 5-8 will contain 0x00 |
| - | if two keys are pressed then byte 3 will contain the number of the key that was pressed first, byte 4 will contain the number of the key that was subsequently pressed, bytes 5-8 will contain 0x00 | + | ... and so on, up to 6 keys. |
| - | and so on, up to 6 keys. | + | When all keys are released bytes 3-8 will be filled with 0x00. |
| * Bytes 9-15: unknown (only seen filled with 0x00's) | * Bytes 9-15: unknown (only seen filled with 0x00's) | ||
| Line 309: | Line 358: | ||
| __Data__ | __Data__ | ||
| - | The data for this response appears to be the same as the "Macro Key Pressed" response. | + | The data for this response appears to be the same as the "Macro Key Pressed" response, except that you will only ever receive information about 1 key being pressed instead of up to 6 when the RED LED is ON. If two keys are pressed Bytes 3-8 will be filled with 0x00. If the RED LED is OFF you'll receive information about multiple keys in bytes 3-8. See "Set Device", above. |
| === Device Information === | === Device Information === | ||
usb_protocol_information.1170884299.txt.gz · Last modified: 2007/02/07 22:38 (external edit)
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
