Complete vpad functions and some docs fixes.

[dkosmari]

• Prototypes for all VPAD functions.
• The note about retail Wii U only having one gamepad was moved to the VPADChan enum.
• Some docs fixes.
• VPADGetButtonProcMode changed its return type to an enum.

[capitalistspz]

Could you also add a comment specifying the VPAD accelerometer unit?

And WUT_ENUM_BITMASK_TYPE for VPADButtons

[GaryOderNichts]

There seems to be one too many unknown parameters.
I assume these map to the touchpad calibration in the Gamepad EEPROM, although there is some confusing scaling done by VPAD.

[dkosmari]

Good catch on the extra parameter, it was a copy-paste mistake.

I don't think that's the same data, considering how it's passed to the underlying function:

• the first pair of unknowns (1, 2) is passed unmodified;
• the second pair (3, 4) is scaled by 0.6672004 and 0.6666667.
• the third pair (5, 6) is passed unmodified;
• the fourth pair (7, 8) is scaled.

So that would imply the max values are scaled, but the min values are not.

The confusing operations (shown in ghidra) seem to be just the way the compiler does the unsigned int to double conversion. The magic constants even change with -ffast-math.

The functionally equivalent of that function seems to be:

int32_t
VPADWriteTPCalibrationValueToEEPROM(VPADChan chan,
                                    uint16_t unknown1,
                                    uint16_t unknown2,
                                    uint16_t unknown3,
                                    uint16_t unknown4,
                                    uint16_t unknown5,
                                    uint16_t unknown6,
                                    uint16_t unknown7,
                                    uint16_t unknown8)
{
    const float x_ratio = 854.0f / 1280.0f; // very close to, but not exactly 0.6672004
    const float y_ratio = 480.0f / 720.0f; // 0.6666667, exactly 2.0f/3.0f when rounding to nearest even
    return __VPADWriteTPCalibrationValueToEEPROM_impl(chan,
                                                      unknown1,
                                                      unknown2,
                                                      (uint16_t)(unknown3 * x_ratio),
                                                      (uint16_t)(unknown4 * y_ratio),
                                                      unknown5,
                                                      unknown6,
                                                      (uint16_t)(unknown7 * x_ratio),
                                                      (uint16_t)(unknown8 * y_ratio));
}

[GaryOderNichts]

Confusing to me were the constants they are scaled with. 854.0f / 1280.0f would make sense though.

The parameters are shuffled by the other function before being written to the EEPROM using CCRCDCPerSetUicConfig:

  val[0x0] = bswap16(unknown3);
  val[0x1] = bswap16(unknown4);
  val[0x2] = bswap16(unknown7);
  val[0x3] = bswap16(unknown8);
  val[0x4] = bswap16(unknown1);
  val[0x5] = bswap16(unknown2);
  val[0x6] = bswap16(unknown5);
  val[0x7] = bswap16(unknown6);

[dkosmari]

I assumed the values would just be written in the same order. I'll rename the unknowns to match the libdrc docs.

[dkosmari]

Could you also add a comment specifying the VPAD accelerometer unit?

Isn't that the same as the KPAD accelerometer? It's measured in Gs (Earth's gravitational acceleration.) So at rest, the magnitude should be 1.0f.

Oh no, I just noticed... the field is named accelorometer. How did nobody notice that?

And WUT_ENUM_BITMASK_TYPE for VPADButtons

Done.