Almost. R2 points to a cut-down version of that struct (which is used internally). These are the 'public' structs...
struct joystick_read_dev_info_struct {
uint8_t joystick_id;
char *device_path;
char *manufacturer;
char *product;
char *serial;
uint8_t number_axes;
uint8_t number_buttons;
};
struct joystick_read_axes_info_struct {
uint32_t type;
char *name;
int32_t min;
int32_t mid;
int32_t max;
int32_t val;
};
The 'values' code just returns a bunch of int32s.
The 'type' is one of:
#define AXIS_HATX 1
#define AXIS_HATY 2
#define AXIS_DPADX 3
#define AXIS_DPADY 4
#define AXIS_X 5
#define AXIS_Y 6
#define AXIS_Z 7
#define AXIS_RX 8
#define AXIS_RY 9
#define AXIS_RZ 10
#define AXIS_SLIDER 11
which I think I just made up. I cannot remember, to be honest. This list may grow over time, but I don't plan to change it. As USBJoystick discovers the device, it enumerates the axes and uses these to indicate which is which.
For the 'classic' Acorn/SerialPort/RTFM interface, I have an 'auto map' function which looks for DPADXY, then HATXY, then XY to work out which axes to use.
With the newer code, you just get them all and decide yourself which ones you want to use.
You could well be right about getting the primary thumb stick. Not a bad plan. But I bet there are devices which do things differently! There are workarounds in USBJoystick for the XBOX360 controller! (which I only out in as I have such a controller, and I think it's commonly copied)
