A thread to collect and discuss some ideas that have arisen to further improve the DS4 mode for more user comfort.

Emulate a Bluetooth connection while wireless

Currently the driver always presents the emulated DS4 as a USB device. This detection is based on the fact that DS4Windows relies on the Input Report Length (in bytes) to distinguish between a real wired/wireless DS4 or other peripherals like the Sony wireless adapter. Presenting wired as wired and wireless as wireless would have a few advantages like users could keep the idle disconnect or disconnect on macro commands which is already possible with a hardware DS4. This would make the driver operation even more transparent to the user and switching between DS3 and DS4 as input device would be even more seamless.

Implementation

• An additional HID Report Descriptor would be introduced mimicking the expected properties when a real DS4 is connected via Bluetooth instead of USB.
• Report layout and length differences need to be considered at the translation logic helper functions.

Pros

• DS4Windows can display the correct connection status when wireless.
• DS4Windows can keep authority over idle disconnect preferences
• DS4Windows can utilize the existing disconnect on command features (macros and other logic).

Cons

• Bluetooth-specific protocol differences need to be addressed
  • CRC32 calculation/validation happens wireless only and the driver would need to emulate it to comply with the existing validation logic.

Doubled Inputs/Exclusive Mode

Since the driver emulates a "proper" HID-compliant device, games with low level HID API support (or even DirectInput) can "see" the original controller and its inputs in addition to the controller DS4Windows emulates. A few ideas exist to address this issue.

Exclusive open handle

The "classic" method that was implemented in early revisions of DS4Windows. Basically opens a handle to the HID collection with an exclusive flag which in turn prohibits any other process from opening and therefore enumerating the original device. This method should be considered obsolete and unreliable since design changes within the Windows OS itself make this hack more and more "hit and miss" or simply impossible on some systems.

HidGuardian

No comment on why this is no long-term solution 😆

HidHide

Next Beta child 😉 introduces another dependency, will definitely work but a topic for another day.

Custom HID device emulation

DS4 mode could be extended or replaced with another completely artificial HID Report Descriptor only containing the bare minimum definition for a fixed size wendor-defined input report. Only customised applications would be able to "understand" the data exposed by this device, so standard gaming input APIs wouldn't pick up this device and therefore no exclusive trickery or blocking processes would be required.

More to come 😁