Games built with Unity's new input system do not work with wireless PS4 controllers in Steam

[Trolygon Studios]

Unity team says this is a bug with the Steam client:

https://issuetracker.unity3d.com/issues/input-system-dualshock4-controller-returns-random-input-values-when-connected-via-bluetooth-while-steam-is-running

[austinp_valve]

Thanks for bringing this to my attention. I don't think this is actually a Steam bug, but an issue where Unity doesn't handle the PS4 controller's extended mode HID reports. I will send an email to our Unity contact with info on how they can fix this. I am also pretty sure the Unity plugin, Rewired, handles this properly so you could try that out while you're waiting on a fix.

My mental model here for what you're doing is 1) having PS controller support on, 2) launching your game from the unity editor without the overlay attached because if the overlay did attach I'd expect you to see either an emulated Xbox360 controller or no controller at all.

In that thread they mention the Windows gamepad test dialog (joy.cpl) but Steam requires the overlay to override inputs so we aren't doing any "hacking of the input stack" for this program. In Windows there's a known issue where if you enable the extended report mode to be able to read motion data, do rumble, or setup the light bar on a BT connected DS4 controller it will stop working properly over DirectInput. Joy.cpl uses DirectInput which is why it stops reporting data. Steam, other remapping programs such as Ds4Windows, and an unknown number of games use libraries that enable this extended report mode so that we can rumble or use the lightbar over BT so it's important to handle this case because you don't know what other programs might have run before the user launches your game.

What's happening under the hood when the extended report mode is enabled is that the USB report structure changes and the data in the input report is shifted down by 2 bytes. If not handled the extended report will end up putting an incrementing packet counter into the trigger data which is what is probably causing the "random trigger input" that the OP is reporting. Nothing else changes about the report other than the byte shift, so all that's needed to handle this is to read the first byte and either proceed normally or move the pointer to your PS4 controllers state structure 2 bytes further into the buffer. Example code for handling this can be found here: https://github.com/libsdl-org/SDL/blob/main/src/joystick/hidapi/SDL_hidapi_ps4.c#L857