Game controller button number incompability between SDL2 and other tools (Windows' and online tools)

I'm trying to make a 1 to 1 mapping between physical game controller device and virtual device (vJoy). What I want to achieve is when button no X is pressed on physical device, make button no X pressed on virtual device.

Since I'm trying to map 1-1 between physical and virtual controller buttons&axes, I shouldn't have any business with mapping. So I decided to use SDL2 library's 'Joystick' related functions instead of 'GameController' related functions.

Input (Physical) => MyApp => Output(vJoy)

I can achieve 1-1 correspondance with almost all of my controllers except one, which is a PS4 controller.

With SDL input read functions(code below), I get these:

When I press press leftshoulder button, event.jbutton.button says 9

When I press press rightshoulder button, event.jbutton.button says 10

(It also says 9 and 10 in game controller mode instead of joystick mode, same. I confirm I'm not mistakenly using controller mode by trying same method with other controllers without changing anything)

SDL_Init(SDL_INIT_JOYSTICK | SDL_INIT_EVENTS);
SDL_JoystickEventState(SDL_ENABLE);
SDL_Event event;

while(SDL_WaitEventTimeout(&event, 50))
{
    switch(event.type){
        case SDL_JOYDEVICEADDED:
              m_Joystick = SDL_JoystickOpen(device);
        break;
        //
       case SDL_JOYBUTTONDOWN:
       case SDL_JOYBUTTONUP:
               qDebug() << "JoystickButton(" << QString(SDL_GameControllerGetStringForButton((SDL_GameControllerButton)event.jbutton.button)) << ")" << event.jbutton.button<< " -> " << event.jbutton.state;

      break;

    }
}

But when I test it with other tools, they give 4 for leftshoulder and 5 for rightshoulder as button numbers.

0-) My App Case

LeftShoulder button => 9

RightShoulder button => 10

1-) Windows' internal game controller utility (index starts from 1, which makes 4-5)

2-) Result from https://gamepad-tester.com/

3-) Result from https://greggman.github.io/html5-gamepad-test/

Since I'm using Joystick related functions, I expect to read inputs as is, without mapping. But SDL2 result seems different from others. Since

1 - What should I do to read joystick input so that it will give the same result with other tools

2 - What is wrong with SDL2 and my code?

SDL2 is trying to protect you from poor standardization of gamepad inputs. It reorders buttons to match its own standard button ordering based on the physical location of each button on the gamepad. The ordering is defined by the SDL_GamepadButton enum. That's where "9" comes from, SDL_GAMEPAD_BUTTON_LEFT_SHOUDLER has value 9. In SDL2, any correctly-mapped gamepad will have the L1 button at index 9.

Gamepad API (used by online tools) is doing the same thing. Gamepad API defines a Standard Gamepad which has "Top left front button" as buttons[4]. In Gamepad API, any correctly-mapped gamepad will have the L1 button at index 4.

You can convert between SDL2 and Gamepad API buttons fairly easily because they both define essentially the same set of standard buttons.

The Windows game controller utility (joy.cpl) doesn't try to remap gamepad buttons. It's using DirectInput API, which chooses button indices based on the HID usage identifier assigned to each button input.

Putting it all together:

> Since I'm using Joystick related functions, I expect to read inputs as is, without mapping.

This is "as-is". SDL2 knows the exact layout of the DS4 input report and reads button and axis values out of the report buffer. There's no remapping happening, the inputs are always correctly mapped.

> But SDL2 result seems different from others.

Yes, it uses a standard button ordering that's specific to SDL2.

> 1 - What should I do to read joystick input so that it will give the same result with other tools

Which other tools? They all are slightly different. If you want to convert between SDL2 and Gamepad API you can use the table above.

> 2 - What is wrong with SDL2 and my code?

Nothing, gamepads are just complicated and poorly standardized.