HIDTest-log-elite.txt
To get the Elite controller to show up in the Network Client (v0.4), I use the Mac (OS X 10.12.6 Sierra) 360Controller driver (latest 0.16.9). It isn't detected by the default Xinput config [vid=0x7331,pid=0x1337], but shows up with [vid=0x045E,pid=0x02E3]. I've used the computer HIDTest (v0.2) (as the Wii U version can't see the controller over the network) to work out all the buttons and the triggers, and they all work fine.
However, the analog sticks (which affect two bytes per axis, with endpoints 0080 and FF7F - I'm not sure what the first byte shows, as it doesn't vary smoothly from 00 to FF - that's why I initially filed this as 'random values except at endpoints' - is this in fact the less significant half of the value, and thus noisy?) have a range of 80 at min, through 00/FF neutral, to 7F maximum (i.e. left and up are negative - counting down from FF).
I've put lines in the config file like:
VPAD_L_STICK_X = 0x07,0x00
VPAD_L_STICK_X_MINMAX = 0x80,0x7F
VPAD_L_STICK_X_DEADZONE = 0x10
but HID-to-VPAD(v0.9k) seems to want unsigned values (min 00, neutral 80, max FF).
5/11/18 I've checked with the authors of the driver, and Xinput is supposed to have a stick range of -32768 to 32767 (the four digits of hex I saw change per axis), so the problem does seem to be in the translation to a format the Wii U can understand, rather than a problem with the driver giving unexpected-for-Xbox readings.
I enclose a terminal log from HIDTest, with comments showing which bytes do what, and what I pressed when.
HIDTest-log-elite.txt To get the Elite controller to show up in the Network Client (v0.4), I use the Mac (OS X 10.12.6 Sierra) 360Controller driver (latest 0.16.9). It isn't detected by the default Xinput config [vid=0x7331,pid=0x1337], but shows up with [vid=0x045E,pid=0x02E3]. I've used the computer HIDTest (v0.2) (as the Wii U version can't see the controller over the network) to work out all the buttons and the triggers, and they all work fine.
However, the analog sticks (which affect two bytes per axis, with endpoints 0080 and FF7F - I'm not sure what the first byte shows, as it doesn't vary smoothly from 00 to FF - that's why I initially filed this as 'random values except at endpoints' - is this in fact the less significant half of the value, and thus noisy?) have a range of 80 at min, through 00/FF neutral, to 7F maximum (i.e. left and up are negative - counting down from FF).
I've put lines in the config file like: VPAD_L_STICK_X = 0x07,0x00 VPAD_L_STICK_X_MINMAX = 0x80,0x7F VPAD_L_STICK_X_DEADZONE = 0x10 but HID-to-VPAD(v0.9k) seems to want unsigned values (min 00, neutral 80, max FF).
5/11/18 I've checked with the authors of the driver, and Xinput is supposed to have a stick range of -32768 to 32767 (the four digits of hex I saw change per axis), so the problem does seem to be in the translation to a format the Wii U can understand, rather than a problem with the driver giving unexpected-for-Xbox readings.
I enclose a terminal log from HIDTest, with comments showing which bytes do what, and what I pressed when.