nefarius/dshidmini

Virtual HID Mini-user-mode-driver for Sony DualShock 3 Controllers

DsHidMini

Virtual HID Mini-user-mode driver for Sony DualShock 3 Controllers

🚨 What to expect with Version 3 🚨

Next major version is in progress! Here's an overview of what you'll get:

• New driver installer
• New configuration app
• ARM64 support
• Full Windows 11 compatibility
• Complete LED customization
• Customize dead-zone thresholds
• Customize HAT/POV behaviour
• Adjust rumble strengths
• Switch DPad to individual buttons
• Customize the Quick-Disconnect button combination
• Configure flipping/inverting axes
• Xbox 360 Emulation out-of-the-box
• ...and maybe more?

Stay tuned!

Summary

DsHidMini is a self-contained, low footprint and feature-rich user-mode driver for Microsoft Windows 10/11. It presents the controller as a configurable variety of fully standard-compliant HID devices to the system and all games built on common APIs like DirectInput, Raw Input and the low-level HID API. XInput-emulation further increases the support in modern games built with only Xbox controllers in mind. The driver supports both wired connections by handling USB communication and wireless connections by building upon the BthPS3 driver suite. An optional .NET configuration tool is provided to alter driver behavior to fine-tune it to specific games or other use-cases.

Features

• Bluetooth support if used in conjunction with BthPS3 (requires at least v2.0.144 or newer)
• Automatically pairs the controller to Windows Bluetooth (if Bluetooth host radio is present)
• Multiple configurable HID Report Descriptors for wide range of compatibility
  • Single Gamepad device exposing all controls including pressure sensitive buttons
  • Split/multi device emulation to overcome DirectInput axis limits
  • Sony sixaxis.sys emulation (both wired and wireless)
  • DualShock 4 emulation for compatibility with DS4Windows
  • Xbox Controller emulation (XInput) for best compatibility with most modern games
• Quick disconnect (on Bluetooth) by pressing L1 + R1 + PS together for over one second
• Automatic disconnect (on Bluetooth) after idle timeout (5 minutes) expired to conserve battery
• Custom LED states indicate battery charge level
  • Wired: Charging will cycle through 1 to 4, if fully charged will stay on 4
  • Wireless: 4 = Full, 3 = High, 2 = Medium/low, 1 = Low/dying
• Rumble exposure via Force Feedback
  • The rumble motors are exposed as Force Feedback effects, allowing for great game compatibility
• Supports the PCSX2 PlayStation 2 Emulator
  • Controller gets picked up by LilyPad plugin with all device features
• Supports the RPCS3 PlayStation 3 Emulator
  • Controller gets picked up by DualShock 3 handler with all device features
• Supports DS4Windows (requires at least Version 2.2.10 or newer)
  • Controller gets presented as a DualShock 4 compatible variant
  • Read #40 for details about XInput and DS4 emulation
• Supports RetroArch emulation platform
• Supports x360ce for XInput emulation
• Supports Dolphin Emulator
• Supports DuckStation - PlayStation 1, aka. PSX Emulator

What's missing

Check the ⚡ issue tracker ⚡ for work-in-progress or known bugs!

The following features are not available (and most probably won't in the near future until more contributors join the party):

• Motion controls a.k.a. SIXAXIS (Gyroscope, Accelerometer)
  • Contributions welcome!
  • See #217
• Navigation Controller
  • Majority is done
  • See #48
• Motion Controller
  • Not considered in design at all

For in-progress features and bug-fixes please consult the issue tracker.

Technical details

How it works

DsHidMini is a filter driver sitting below mshidumdf.sys and acts as a function driver for USB and Bluetooth through the User-mode Driver Framework Reflector, handling translation of incoming HID I/O traffic to underlying USB/Bluetooth I/O and vice versa. On USB it replaces the Windows stock drivers for the Sony hardware and presents the device as a variety of user-configurable HID devices (see documentation). On Bluetooth in conjunction with BthPS3 it replaces the need for Shibari as the driver directly communicates over wireless channels and takes care of the necessary translation logic. As a user-mode driver it has limited access to the registry, therefore device-specific settings are stored and retrieved using the Unified Device Property Model API. Most of the core HID heavy lifting is done by the amazing DMF_VirtualHidMini module which greatly reduced the need for boilerplate code and sped up development tremendously.

Environment

DsHidMini components (drivers, utilities) are designed for Windows 10, version 1809 or newer (x86, x64).

The dependencies used in DsHidMini don't exist in Windows 7/8/8.1 so they can't be supported.

How to build

Prerequisites

• Step 1: Install Visual Studio 2022
• Step 2: Install Windows 11, version 22H2 SDK
• Step 3: Install Windows 11, version 22H2 WDK
• Step 4: Clone the Driver Module Framework (DMF) into the same parent directory.
  • Important: requires at least v1.1.83 or newer
  • Build the DmfU project with Release and Debug configurations for all architectures (x64 and Win32).

You can build individual projects of the solution within Visual Studio.

Licensing

This solution contains BSD-3-Clause and other licensed components. For details, please consult the individual LICENSE files.

This is a community project and not affiliated with Sony Interactive Entertainment Inc. in any way.

"PlayStation", "PSP", "PS2", "PS one", "DUALSHOCK" and "SIXAXIS" are registered trademarks of Sony Interactive Entertainment Inc.

Documentation

Take a look at the project page for more information.

Installation

Pre-built binaries and instructions are provided on the releases page.

Support

To get support please follow these guidelines.

Sponsors

Sources & 3rd party credits

The following awesome resources have made this project possible.

Related projects

• nefarius/ScpToolkit
• nefarius/FireShock
• nefarius/AirBender
• nefarius/WireShock
• FirstPlatoLV/EmuController
• Arduino - felis/USB_Host_Shield_2.0 - PS3 Information

Dependencies

• Microsoft/Driver Module Framework (DMF)
• Microsoft - DMF - HID minidriver module
• Microsoft - DMF - VHidMini2DmfK and VHidMini2DmfU Sample Drivers
• Ultralightweight JSON parser in ANSI C
• HIDAPI - Multi-Platform library for communication with HID devices

Tools & references

• Eleccelerator Wiki - DualShock 3
• Eleccelerator - USB Descriptor and Request Parser
• HID Usage Tables
• PS3 and Wiimote Game Controllers on the Arduino Host Shield: Part 2
• ribbotson/USB-Host
• HID: sony: Update device ids
• linux/drivers/hid/hid-sony.c
• The HID Page

DevOps

• AppVeyor CI
• NUKE build system

dshidmini's Issues

PCSX2 and pressure sensitive buttons.

I just finished testing the PCSX2 mode.

There are a couple of problems I encountered unless I have done something wrong.

When enabling the PCSX2 mode, the pad work perfectly in PCSX2 (V1.6.0 Stable), can map all the buttons, but, no pressure sensitive buttons.
When you enable the "Mute digital pressure buttons" Now, the face buttons and shoulder buttons are mapped as sliders, so they are pressure sensitive. But, you can't map Start, Select and both L3 and R3. And also, for some reason the Left stick keeps continuously pushing to the left and can't make it stop, even when setting a high deadzone in PCSX2.
When checking the pad in "joy.cpl" everything is correct regarding the "left stick" pushing left. I noticed that only X and O are sliders there, if that matters.

The weird behavior also occurs in other DirectInput applications.

The way you're supposed to map is as follows:

• Enable the Mute option
• Map all axes and buttons with pressure values (Face, Shoulder, DPad, Thumbs, Triggers)
• Disable mute
• Map Select, Start, L3 and R3
• Save
• Done!

Cheers

Expose last pairing result as device property

Issue

Currently it's hard to tell if pairing succeeded without a trace log.

Proposed solution

Introduce another device property which stores the last NTSTATUS reported by the pairing function and display it in DSHMC.

Replace current verbose wireless reader implementation with Dmf_DefaultTarget

Currently the Bluetooth continuous input reader is very verbose because of the use of all the WDF objects in need.

Consider porting it to the DMF Module Dmf_DefaultTarget instead.

Rumble/LED state changes lost if sent too fast to the controller

The issue

2 or more Output Reports sent too fast to the controller will cause only the first to be correctly interpreted and only after commands stop being received by the controller for some time.

Summary

LEDs and Rumble state changes are sent in Output Report (OutRep) to the controller that always contains both informations and represent the current status of the controllers LEDs and Motors. If 2 or more OutRep are sent too close to each other only the first will be correctly interpreted by the controller and its content will only be in effect when the controller stops receiving new OutRep. Some models of ps3 controllers (e.g.: sixaxis CECHZC1U, DualShock 3 CECHZC2U rev1) are more prone to this issue, though chances are it can happen with any controller when commands are sent too fast (reproduced with a DualShock 3 CECHZC2U rev2).

Examples (tested with Sixaxis controller, model CECHZC1U)

• Turn Rumble ON -> wait 15ms -> Turn Rumble OFF // Result: Rumble OFF OutRep is lost, Rumble stays on
• Set LED 1 -> wait 15ms -> Set LED 2 // Result: LED 1 will stay set
• Set LED 1 -> wait 500ms -> Set LED 2 -> wait 15ms -> Set LED 3 100 times with 15ms waiting time between repeats // Result: Led 1 will be set, Led 2 will be set only after the controller stops receiving the "set LED 3" OutRep.

Problems caused by this

The bigger issue is a "Turn Rumble OFF" command being lost, making the controller vibrate for a time longer than what the aplication/game intended (as reported by #16 ) or for it to continue vibrating indefinitely until a new valid "Turn Rumble OFF" command is received.

Reproducing the problem

This issue can be easily reproduced by using this Auto DsHIDMini Test Tool along with the latest DsHidMini driver.
The controller needs to be the only ps3 controller connected to the computer, be in "SXS" mode and the Deduplication and Output Rate Control functions need to be both disabled.

By choosing to run the Auto DsHidMini Test Tool on the "auto" setting, it will:

• Set LED 1 / Turn Rumble ON -> wait "X"ms -> Set LED 2 / Turn Rumble OFF, then repeat this 20 times
• After it finished repeating 20 times, it will make the waiting time shorter, then reset and start sending the commands sequence 20 times again. The "X" waiting time starts at 110ms and decreases by 10 every cycle of test, until it tests with 1ms and then with no waiting time.

The expected behavior is for the controller to vibrate for only a instant before stopping and setting LED2 as ON. As the waiting time between the commands start getting shorter, the controller will start failing to correctly execute the Output Report, not setting LED 2 as ON and continuing to vibrate for ~500ms. Controller more prone to the issue (like the Sixaxis) will start failing at around a 90ms waiting time, while good controllers will only fail below the 20ms range.

Keep in mind that because the Auto DsHidMini Test Tool has to depend on the windows scheduler, waiting times in the test that are shorter than 16ms will start to get inaccurate (e.g.: a waiting time of 10ms will probably result in a 15 or higher waiting time in real time)

Testing

Because the Sixaxis can't rumble, the Output Report being received could only be verified by checking the LED state.
With the test tool, waiting times shorter than 100ms resulted in the sixaxis failing to process the incoming Output Report sometimes, with the frequency increasing as the waiting time got shorter.
Since the waiting time in the tool is not real-time accurate, wireshark was used to see the actual time-stamp of the OutReps being sent. It was verified that a packet was lost after being sent ~95ms after another one.

Testing with a Dualshock 3 Model CECHZC2M only resulted in a fail when Output Reports were sent with a time difference of 25ms, though the acceptable time difference between packets is not constant, as some times it would ignore Packets sent to it that were sent slower than other ones.

Problems with the current solution

The deduplication function will discharge Output Requests that are 100% equal to the last successfully sent one, so a game spamming "rumble on" will cause only the first request to be sent to the controller and the rest discharged until a different command is sent ("rumble off", "rumble in another intensity").
The Output Rate control function discharges every new command received if they arrive too close to the last one sent. This ensures the first command received is actually processed by the controller, since as stated in the Examples section, when multiple commands are sent too fast to the controller all commands after the first are ignored and the first sent one will only be effective when the controller stops receiving new ones.

While these functions mitigate the issue, they are prone to the following problems:

• If a game is sending multiple times, during the span of some seconds, the command "Rumble for 1s" in order to refresh its duration, deduplication will ignore new commands after the first, making the controller stop rumbling before the expected time
• Output Rate control can cause important commands to be discharged. If a "Rumble OFF" command is sent too close to a "Rumble ON forever" the former will be discharged, making the controller keep vibrating and forcing the user to turn off the controller or cause a new rumble event in the hope that another "Rumble OFF" is sent

Proposed solution

• Implement a Async Countdown timer that starts counting from the moment a Output Report is sent
• If the Countdown Timer is active, save new received commands in a cache
• The cache should hold only 1 command, with new received commands overwriting the previous saved one, ensuring only the latest received command is saved
• After the Timer finishes counting the cached command is sent, the cache cleared and the Countdown Timer restarted
• If there are no command on cache when the Countdown Timer finishes then the Timer is disabled, ensuring a new received command is immediately sent with no delay

The image below illustrate the proposed solution:

Because the cache only holds the latest received command on the period the Countdown Timer is active there is no risk of a "To send" commands list getting longer and resulting in a delay in Rumble/LED changes events. Though there are still lost commands, only the latest received one is of actual importance, since it contains the most recent state the controller should be in.

To-do

• Verify output report loss on cable

Vibration Erratic with latest binaries (but it kinda works)

Hey Nefarius, great to see you working on new stuff again! I'm seeing a problem with the new version, which seems to cause vibration events to persist until the next vibration command is sent or something like that? Generally the vibration seems to be very inconsistent overall. For example shooting an automatic weapon has vibration for the first few shots then nothing. Sometimes crashing into something causes a continuous vibration until something else happens. I have only tested in GTAV as thats the only game I have that I use a controller with.

PS3 DS3 Controller in DS4 mode via BT. Controller model CECHZC2E
OS: Windows 10 20H2 19042.867// dshidmini_v1.0.50.0 // DS4windows 2.2.10 x64 // BthPS3 v1.3.127 // Vigem 1.17.333.0
Removed all traces of SCP and Shibari drivers using driver store explorer.
Same behaviour either wired or BT.

Is there some way I can produce a log for you with something useful in it?

Dualshock 3 controller does not work

Sony Dualshock 3 controller connected to the PC with the default USB cable. Tried connecting it to a front USB 2.0/3.0 or directly to an motherboard USB 2.0 connector. DSHMC shows the "No compatible devices found" message. No previous DS3 drivers were installed.

Windows 10 Pro 20H2 64bit
DsHidMini 1.1.84.0 (x64)

Windows device manager shows the controller with device type "Nefarius HID Devices". The device status is (german Windows, I just post the orginal messages):
Das Gerät kann nicht gestartet werden. (Code 10)

{Gerät-Zeitüberschreitung}
Das Zeitlimit des angegebenen E/A-Vorgangs auf %hs wurde erreicht, bevor der E/A-Vorgang abgeschlossen wurde.

The windows event log shows this:
Beim Start des Geräts USB\VID_054C&PID_0268\5&887acb0&0&6 ist ein Problem aufgetreten.

Treibername: oem17.inf
Klassen-GUID: {2b959c9d-a4ed-4464-809d-0f1118cf055d}
Dienst: mshidumdf
Untere Filter: WUDFRd
Obere Filter:
Problem: 0xA
Problemstatus: 0xC00000B5

What kind of information could help you narrow this down?

Thoughts on improving DS4 mode

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 😁

P1 PS3 controller shows as P4 on LEDs

Not sure if this is a known issue or not. For the time being, I am testing with only 1 PS3 controller. Whether connected via USB or BT, the LED on the controller always shows P4 (not P1).

Decode and utilise potential device identification report packet

Related to #16, #20 and possibly #3

Some interesting unused packets exchanged by controller and PS3 have been documented for ages but not really further decoded and documented.

Example implementation

As documented on the Wiki send a Class Interface GET_REPORT request with value 0x0301 to the controller which returns approximately 44 bytes of (non-zero) data.

UCHAR tmpBuf[64];

if (NT_SUCCESS(USB_SendControlRequest(
	pDevCtx,
	BmRequestDeviceToHost,
	BmRequestClass,
	GetReport,
	0x0301, // "Identification" request(?)
	0,
	tmpBuf,
	64
)))
{
	DumpAsHex("EXPERIMENTAL", tmpBuf, 64);
}

Packet dumps

After a bit of testing with various controllers I have in my stash I am delighted to observe a consistent pattern of responses with different (yet undisclosed) fields per controller model/revision 🙂

Eleccelerator Wiki

00010400070C010218181818090A1011121300000000040002020202000000040404040000040001020700170000000000000000000000000000000000000000

CECHZC2E A1

00010400080C010218181818090A1011121300000000040002020202000000040404040000040001020700170000000000000000000000000000000000000000

CECHZC2U A2

000104000B0C010218181818090A1011121300000000040002020202000000040404040000040001020700170000000000000000000000000000000000000000

CECHZC2E B1

00010401030C010218181818090A1011121300000000040002020202000000040404040000030001020000170000000000000000000000000000000000000000

SIXAXIS

000102000308010217171717090A0000000000000000040002020202000000040404040000010600000000000000000000000000000000000000000000000000

PANHAI

00010300050C010218181818090A1011121300000000040002020202000000040404040000020102006400170000000000000000000000000000000000000000

"CECHZC2U" (DUALSHOCH)

00010300050C010218181818090A1011121300000000040002020202000000040404040000020102006400170000000000000000000000000000000000000000

More to come 😁

Add D-Pad as buttons in GPJ and SDF mode

Some games that do support D-Input don't recognize the D-Pad in T-Hat format (e.g.: Metal Gear Solid 2). Having the ability to use the D-Pad as common buttons instead of the T-Hat format is needed to get around this.

Make the controller in DS4 Mode hidden by default

Related to #23

The issue

DS4 Mode presents the controller as a HID compatible Gamepad. Because of this, this device needs to be hidden with HidHide/HidGuardian, which adds complexity to the setup.

Proposed solution

Change DS4 Mode HID Descriptor so that:

• The Usage page is Vendor-Defined
• Usage is 0x01 (Generic Desktop Control?)

This branch of DsHidMini has these changes implemented.

Making this changes makes the controller be presented as a vendor defined device, so it is mostly ignored by aplications. The usage needs to be 0x01, as setting it to 0x04 or 0x05 (Joystick and Gamepad respectively) still make the original controller detectable by some aplications.

Potential issues with the proposed solution

DS4Windows changes

DS4Windows only checks for devices if their usage is 0x04 or 0x05. Since the DS4 Mode usage will 0x01, 0x01 detection support needs to be implemented on DS4Windows side.

This branch of DS4Windows has the changes implemented.

DS4Windows does not detect the device if DS4 Mode is the default mode on driver installation

If DsHidMini's .inf file is altered so the default mode on installation is "4" (DS4 Mode), the device will not be picked by DS4Windows for unknown reasons. Changing to another mode and back to DS4 mode again will not fix the issue.

If the default mode on installation is any other and the mode is changed to DS4 Mode afterwards then DS4Windows will detect the device.

LEDs flickering between values on Bluetooth

Issue

Some controllers (with aged or low quality battery or supporting circuitry) start to report a jittering (rapidly altering) battery status value which in turn causes to frequently update the LED indicating charge by default.

Suggested solution

Only check for state changes every minute or so; battery capacity should drop slow enough that a state change only once per minute would be more than enough.

Strategy to deal with aftermarket devices

New software, old issues 😅 As mentioned many times the DS3 has seen its fair share of clones circling around, some of them with weird changes in the firmware/ASIC that the original PS3 firmware seems to happily accept but causes all sorts of weird issues on Windows (USB by observation is usually more "forgiving" and Bluetooth support is the Wild West in regards of compatibility).

While I stand true by my statement that I have mentally closed this chapter and have no interest in investing anymore of my time to dig in to come up with weird workarounds to support these devices, I do wanna explore possibilities to aid users in detecting genuine and fake devices.

Unfortunately the PS3 hardware doesn't really offer much reliable properties to identify their origin with a 100% certainty (despite all the misinformation spread online). Those include:

Hardware

• Basic casing and overall look and feel of the controller
  • Nope. Very easy to spoof and hard to detect differences without additional tools or experience.
• Manufacturer label on the back
  • Nope. These stickers can be faked/spoofed with ease, including all the official fonts and certification symbols. Subtle hints exist like the stickers being slightly off position, which indicates human labour.
• Insides of the controller (PCB, choice and layout of components, quality of assembly, hints of stains of cheap solder flux etc.)
  • This is amongst the best methods of identifying genuine from aftermarket devices, although again not practical for the average user, especially since some aftermarket devices are built so cheap they might not survive reassembly.

Software

• Vendor (0x054C) and Product (0x0268) IDs (USB only)
  • Nope. They're 99.9% of the time spoofed (copied from original Sony ones). The one mechanism meant for exactly that is totally ruined by an industry of professional counterfeiters 🙂
• Product name (USB and Bluetooth)
  • Eh, yesn't 😆 the official name the DS3 should report is PLAYSTATION(R)3 Controller (both in the USB descriptor and the response to the HCI Remote Name Request). However the past has shown different results. Some users even reported they own genuine hardware which uses PS3 GamePad as a name, so more confusion on the horizon.
• Device MAC address
  • This might be the lead we're looking for; the OUI part (first 3 bytes) of a MAC address identify the vendor/manufacturer and could help to distinguish the devices by assuming, that Sony sourced "high quality" parts that are not used by aftermarket devices, because the bill of materials would be too high.

More to come.

Rumble not working with bluetooth

DsHidMini 1.0.18.0
BthPS3 1.3.127
ViGEmBus 1.17.333
DS4Windows 2.2.10
Genuine DS3
Asus BT400 BT adapter

I've got my controller working almost perfectly with DS4Windows as an emulated xbox 360 controller, however, I cannot get rumble to work. Is there some hidden setting somewhere I am missing? Rumble did work quite well with Fireshock/Shibari.

Remove unused 14th button from GPJ and SDF mode

There is a 14th button in SDF mode and in the Gamepad part of GPJ that is not linked to any button/axis of the real controller. Since it's useless it should be removed to avoid confusion/keep things clean.

Connecting over Bluetooth?

I have BthPS3 installed from my previous Shibari.DOM.Server installation but the SIXAXIS controller I use does not automatically reconnect when disconnected from USB and pressing the PlayStation button.
How can I pair the controller to work over Bluetooth?

Allow setting LED effects

There are advanced LED effects that can be set on genuine controllers, making LEDs blink by sending only 1 command instead of manually turning on and off repeatedly . It would be nice if the driver allowed these effects to be set. Example of usage: make the "Dying" battery level LED status be "Blinking LED 1"

Documentation: https://github.com/RPCS3/rpcs3/blob/1213708b72e7d29b4461ec0fd4efffd926772315/rpcs3/Input/ds3_pad_handler.cpp#L21

Examples:

All LEDs ON, but LED 4 Blinking
0100000000FF00FF00000000001EFF05108080FF05108080FF05108080FF05108080000000000000000000000000000000
https://user-images.githubusercontent.com/24910442/113941579-baa2ed00-97d5-11eb-91d1-9b7766ce6b74.mp4

LEDs 1, 2 and 3 blinking. LED 4 also blinking but at a different time
0100000000FF00FF00000000001EFF05108080FF27100032FF27100032FF27100032000000000000000000000000000000
https://user-images.githubusercontent.com/24910442/113941591-c2fb2800-97d5-11eb-806a-399bc724d287.mp4

Replace Dmf_ScheduledTask with DMF_ThreadedBufferQueue

Replace the DMF module DMF_ScheduledTask with DMF_ThreadedBufferQueue. The initial use case for the repeating scheduler doesn't exist anymore since the Output Report rework so switch to a module more appropriate for the current task.

"Finger contact on touchpad" data set as always "ON" in DS4 Mode

On a DS4 USB Input Report, the Bytes 35 and 39 are related to fingers contact with the touchpad. If the MSB of Byte 35 is "0", then "finger 1" is in contact. If on Byte 39 then "finger 2". In DS4 mode, DsHidMini makes Bytes 35 and 39 "0x00", so DS4Windows interprets as if there were 2 fingers in conact with the touchpad all the time. Making the MSB = "1" of bytes 35 and 39 should fix the issue.
sources: https://www.psdevwiki.com/ps4/DS4-USB

Interpret flags in DS4 Output Reports

In DS4 mode in conjunction with DS4Windows, Output Reports protocol 0x11 are sent to the driver containing Light Bar information and Rumble commands. These info are always interpreted by the driver, setting the received rumble values and translating the Light Bar color to LEDs.

In the packets there are flags indicating if the rumble/light bar color values should actually be interpreted, as shown in the image below:

source: psdevwiki DS4-BT

If they are not verified, there is a chance that the values are actually random/garbage data and the driver interpretes them anyway. Although DS4Windows seems to be always sending the correct values regardless of the flags, it should be better if DsHidMini were to mimic the real DS4 behavior on this.

Because there is a flag regarding "Flash", which seems to be related to the "Flash bright" and "Flash dark" bytes, this flag can be potentially useful to ignore Flash/Pulse commands or to translating them to another LED state.

Add single letter to controller's name to help differentiate between modes/multi devices

Things start to get confusing when 2 or more controllers are connected, specially in GPJ mode.
Suggestion: Adding a "(G)" / "(P)" to the start or end of the controller's name on GPJ mode, and the selected mode's name ("SXS", "DS4", "SDF" / "X", "S", "4" ) on the rest.

Fix protocol-agnostic storing of MAC addresses

Problem/cause

USB and Bluetooth report the Host and Device MAC addresses in reverse order, currently one common variable is used for both connection types which is prone to errors reading and writing the value.

Currently this affects DS4Windows; the controller MAC displayed while wireless is correctly translated, while it is in reverse on USB.

Correct

Incorrect

Proposed solution

Consider moving the variable to the connection-specific context memory or make sure only one common byte order (LSB, MSB) is used throughout the entire driver.

Fake/Copy-cat DS3 controller doesn't connect over Bluetooth

Keep in mind: this is a really specific, rare issue and chances are that if your controller is not connecting by Bluetooth it's probably for another reason. If the issue described here ends up not being your case, have a look in our Bluetooth connection troubleshooting section.

The issue

Most fake DS3 controllers work fine over Bluetooth... Most. Some reeeally rare copy-cats controllers don't use encrypted connections on bluetooth. Because Windows sees this as a security hazard it immediately drops the device when it tries to connect. This is something that DsHidMini and BthPS3 can't fix, the only option is to use the controller wired.

Known controllers with this issue

DS3 copy-cat identified as Pro Controller. We have discovered that there are other controllers with different appearances/shells that suffer from the same issue.

How to check

Before trying this, follow the How to Install article's Troubleshooting section to be 100% sure DsHidMini is correctly installed, BthPS3 is working, the controller is correctly paired to the current Bluetooth Host address and everything indicates the controller should be connecting, then:

Adding the Pro Controller to the list of supported devices on BthPS3 list

• Press Win + R to open the Windows Run tool
• On the Run Tool, type regedit and then press OK. Windows' registry editor should open
• Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BthPS3\Parameters
• On the right side, modify the SIXAXISSupportedNames entry
• Add the name Pro Controller to the list (best if you copy and paste the name there, it needs to be a exact match)
• Confirm the change and then close Windows Registry

Checking Windows Event Viewer

• Try connecting your controller wirelessly
• Press Win + X and then open the Event viewer on the appearing menu
• Expand the "Warning" section and then double click on the BTHUSB source entry:
  
• Check if there is a recent (look at the time) "warning" entry that has the same General description, Windows rejected a device connection because the device didn't establish encryption prior to the service level connection, as shown in the image below:
  

Results

• If a warning with the same description exists then you are out of luck
• If the warning does not appear on Windows' event log then your controller is probably failing to connect for another reason and requires a BthPS3 tracing to determine exactly why. Reach us through the proper means so we can give you a hand

Working around the issue (TL,DR: You can't)

The only way is fully replacing the whole Windows' Bluetooth Stack with another KMDF bluetooth stack that checks and accepts in-coming, unsecure DS3 connections. This driver does not exist and probably never will since it's a enormous amount of work for little to no benefit (how many people have this Pro Controller DS3 copy-cat?).

How to uninstall?

How do you uninstall DsHidMini? I can't find any uninstall directions.

Right stick doesnt work properly

Hello people, the issue i'm facing appears when i try to configurate the buttons, the stick seems to be always pressed to only one direction and don't let me set the other buttons of the gamepad or the other directions of the same stick.

Request: option to switch between "single" vs "filling" battery level

This is really similar to #30 , but implemented natively in DSHM, with the option to switch between "filling" (all 4 LEDs on = Full, LED 1 on = Low) and the present LED system (LED #4 on = Full, LED #1 = Low).

Rework update check in DSHMC

• Convert update check to "on demand" (button/link click in UI) instead of calling GitHub API on every program launch
• Also check for new driver version, currently only UI assembly version is used to compare with online tag

Emulate a strength adjustable small motor by using the Big motor

The Issue

Basically, XInput and DS4 devices have 2 motors (big and small) and their rumbling strength is adjustable. Although the DS3 also has 2 motors, the small motor has only one fixed strength.

As DsHidMini is now, every small motor rumble request gets its strength setting ignored by the driver. The problem with this approach is that some games use the small motor for subtle effects almost constantly. Because the DS3 small motor has only one strength, the result can be a strong, constant and annoying rumble instead of a subtle effect (e.g.: racing games having the controller rumbling constantly to emulate the car vibration).

Reproducing

Any modern game that uses XInput and has rumble can be used as a example at some part, but one that's guaranteed to make the user want to turn off rumble is Need For Speed: Most Wanted 2012 and its constant vibration.

Idea for solution

Make small motor commands below a threshold of strength (e.g.: 50%) be converted to Big Motor Commands (as long as there isn't an actual Big Motor command with a greater strength). Above the threshold then just activate the Small motor as the difference on what is intended by the game and the real effect is probably smaller.

To-do

Lots of tests, from pratical tests with games regarding if converting small motor commands to big motor feels odd to finding the best threshold where the small motor should actually be turned on

Transition from BTH to USB problems (latency increase and no input)

When transitioning a controller from BTH to USB, BTH host latency increases exponentially, causing the rest of controllers connected via BTH at the time to disconnect due the high latency, also, the controller that transitioned to USB stops detecting input but still appearing as connected

Steam (Specifically rocket league) will not see the controller as DS4

Hi there Nef! Amazing work as always. Just thought I'd bring this up as an issue (May not be. not sure). So with shibari/Fireshock/BTHPS3 combo steam saw the ps3 controller as a PS4 and so did rocketleague. Worked flawlessly. However DSHidMINI seems to struggle. any of the 4 modes allow steam to see the control (Can maneuver big pic mode no prob) but rocketleague will not recognize any of the inputs. I tried using the DS4 guide but that did not work either. The only way I can get RKL to see it is to use SXAXIS mode on dshidmini and on steam enable Playstation controller support. This allows input but while steam sees it as a playstation control, rkl sees it as xbox. weird! In any case, this may not qualify as a bug but since it worked on the old setup and not on this one, I thought it might.

Controller vibrates on USB using ScpToolkit but does not vibrate with DsHidMini

Vibrating in Scptoolkit wired : https://streamable.com/g0sgyu

DS3 shoulder triggers inverted

DS3 shoulder triggers are inverted to me. 100% when not pressing and 0 when fully pressed.
I installed BthPS3 and dshidmini_v1.1.84.0

Anything I'm doing wrong?

Thank you.

Feature Request: Auto update in addition to update check for dshidmini

Currently I find myself manually copying the new exe over every time there is a new version etc... I think implementing something similar to scptoolkit's old update functionality where it did the work for you and replaced the old exe with the new one would be nice. Even something similar to ds4windows update functionality would be very helpful in my opinion.

Big Motor only rumbles above certain strength value

Summary

Big Motor (BM) commands sent to the controller have two parameters: duration and strength. The values range from decimal 0 to 255. Regarding rumble strength:

• decimal 0 turns off the BM
• decimal 1 should activate the BM at minimum strength
• decimal 255 activates BM at maximum strength

What actually happens is that the BM is only activated at a value far greater than decimal 1. With a controller Model: CECHZC2M (Date Code: 2D) the minimum value is decimal 64.

Testing

• If possible, do these tests with the controller connected by bluetooth
• Set the controller in SXS mode
• Make sure the controller is not hidden by HidGuardian/HidHide. If the controller is hidden with HidHide you can just open its Configuration Utility, disable the "Enable device hiding" box in the devices tab and then reconnect the controller to make it visible again.
• Download and extract this archive
• Run "MightyHIDTest.exe". If it immediately closes then your controller is not in SXS mode or is hidden
• MAKE SURE TO NOT CLICK INSIDE THE BLACK WINDOW OTHERWISE THE PROGRAM WILL CRASH. If you need to select the window to write make sure to click on the top of the command window
• Run the test once (write "1" and then ENTER). Your controller should rumble weakly. If it does not, then the minimum value that makes your controller rumble is greater than decimal 64
• Close the command window

Now, to discover what is the minimum strength that makes your controller rumble, we need to edit the settings.json file in the extracted folder to vary the strength value. First, let's choose a new strength value.

If your controller rumbled with decimal 64, then the next lower value is decimal 63. If it didn't rumble then let's go higher with decimal 65

The reason I'm writing "decimal" everywhere is because we will need to use values in hexadecimal. E.g.:

• decimal 65 is hexadecimal 41
• decimal 64 is hexadecimal 40
• decimal 63 is hexadecimal 3F

So, after choosing the new decimal value you want to test you need to find its hexadecimal representation. You can convert from decimal to hexadecimal by using this site or by looking in the table in the image below, where hexadecimal values are in black and decimal in red:

After having chosen the hexadecimal representation of the new test value:

• Open the settings.json file with a text editor (windows' notepad is enough, just right click on the settings.json file -> Open with -> Choose another app -> Select notepad on the list
• REPLACE the first 2 digits AFTER THE "7F" AS SHOWN IN THE IMAGE BELOW with the new value:
  
• Close the notepad and choose to save changes
• Run MightyHIDTest.exe again, choose "1" again
• Check if your controller will rumble
• Keep trying different values until you find the minimum value where the controller rumbles

Reporting your findings

It would be great if you provided the maximum amount of info regarding your controller and the tests:

• Your controller model, as well as other relevant info (if you could post a photo of the information sticker in the back of your controller it would be great, but it's not a necessity)
• The minimum value that makes your controller rumble (specifiy if the value is in Decimal or hexadecimal. Better yet, inform both)
• A print of your DSHMC tool so it's possible to see the genuine controller check
• The identification property of your controller. Keep in mind that 1) you need to be on the latest released driver 2) be connected by USB for this info to be available on Windows

Proposed solution:

Re-scale BM Strength values to the range that actually activates the motor. If the minimum value is not consistent across all devices then include in DSHMC tool a slider to adjust the minimum value used for the re-scaling function.

Optimise memory handling with output report

Ever since switching to the Interrupt OUT Endpoint the Output Report memory blob should also contain the now necessary Report ID 0x01, so extend the context memory and get rid of this unnecessary alloc/copy/free instruction.

Update all buffer offsets in the helper macros and functions regarding USB and it should be fine.

Make DS4 Mode device hidden by default

The issue

DS4 Mode presents the controller as a HID compatible Gamepad. Because of this, this device needs to be hidden with HidHide/HidGuardian, which adds complexity to the setup.

Proposed solution

Change DS4 Mode HID Descriptor so that:

• The Usage page is Vendor-Defined
• Usage is 0x01 (Generic Desktop Control?)

This branch has these changes implemented.

Making this changes makes the controller be presented as a vendor defined device, so it is mostly ignored by aplications. The usage needs to be 0x01, as setting it to 0x04 or 0x05 (Joystick and Gamepad respectively) still make the original controller detectable by some aplications.

Potential issues with the proposed solution

DS4Windows changes

DS4Windows only checks for devices if their usage is 0x04 or 0x05. Since the DS4 Mode usage will 0x01, 0x01 detection support needs to be implemented on DS4Windows side.

This branch has the change implemented, and because it's only a few lines of changes I don't thing Ryochan7/Mika-n will be against it.

DS4Windows does not detect the device if DS4 Mode is the default mode on driver installation

If DsHidMini's .inf file is altered so the default mode on installation is "4" (DS4 Mode), the device will not be picked by DS4Windows for unknown reasons. If the default mode on installation is any other and the mode is changed to DS4 Mode afterwards then DS4Windows picks the device as normal.

Request: option to give dshidmini priority over lightbar translation

With DSHM already having a good native LED system to show battery level, alongside a charging animation (that DS4W lacks?), it would be nice to have the option of giving DSHM priority over LED states. It would be easier for users, not having to set up the LEDs in DS4W to show the battery level, and it also seems like DS3 -> DS4 battery translation has some bugs (High in DSHM showing up as 100% in DS4W, see @Kanuan for more information); DSHM using its native battery levels / LEDs would instantly solve that issue.

If you want to use your PS3 controller as a Xbox or PS4 Controller, read this

First, know the terms:

• Standard PS3 controller => DualShock 3 (DS3)
• Standard PS4 controller emulation => DualShock 4 (DS4) emulation
• Xbox 360/Xbox One controller emulation => XInput emulation

Main info

If your intention is to use your DS3 as a Xbox controller there are 3 methods:

• [Recommended] Setting the controller in DS4Windows HID Device Mode and using it alongside Ryochan7's DS4Windows. Check the DS4Windows Mode User Guide for instructions.
• [On Beta testing] Setting the controller in XInput HID Device Mode
• Setting the controller in SXS HID Device Mod and using it on Steam with Playstation Configuration Support enabled on its controller settings

For using your controller as a DS4, you need the DS4Windows Mode method above (FOLLOW THE GUIDE! It will NOT emulate a DualShock 4 by itself!)

Remarks on using the DS4Windows HID Device Mode

• Ryochan7's DS4Windows will create/associate a virtual Xbox or DS4 controller when a DS3 in DS4Windows HID Device Mode is detected
• Follow the DS4Windows Mode User Guide for instructions
• DS4Windows app makes it possible to do all kind of customizations on the fly: remapping buttons/keyboard/mouse, output curves, circular-vs-square sticks, macro sequences, etc

Remarks on using the XInput HID Device Mode

• This mode will present your DS3 directly as a Xbox controller to the system, more-or-less how ScpToolKit worked
• In Beta testing as of now on DsHidMini v2
• A significant number of games do not work well with this mode. The game may end-up not detecting the controller, detecting 2 controllers instead of one, having wrong button mappings, randomly stop responding for a few seconds etc. If it works well or not can only be known by testing. See more on the known issues here
• There are no remapping or sticks deadzone settings on DsHidMini for now. If you need those features, use the DS4Windows mode method

Remarks on using the SXS HID Device Mode

• Steam can detect the controller as an actual DualShock 3 and will then remap it into (usually) a xbox controller for Steam games
• Requires Steam's Playstation Configuration Support controller option to be enabled
• Non-Steam games can be launched through Steam by adding them to Steam game list as a local/custom game
• Rumble not supported

Other questions

If you have a question that is not covered in one of the pages linked above, have a look at the Community and Support page on how to properly reach us.

Windows detecting both DS3 and x360 emulated controller (is there a workaround/fix?)

Is there a way to stop windows from detecting the DS3 at the same time as the emulated 360 when using dshidmini with DS4Windows? My games seem to be showing both the xbox and ds3 inputs when I connect a controller

Add Disconnect control to DSHMC

Add some UI element to DSHMC to disconnect the controller from Bluetooth.

DS3 to DS4 battery translation is incorrect

DS4 battery info from the input report is translated as the following in ds4windows:

• 8-15 => 100 %
• 7 => 87 %
• 6 => 75 %
• 5 => 62 %
• 4 => 50 %
• 3 => 37 %
• 2 => 25 %
• 1 => 12 %
• 0 => 0 %

The values used in the current version of dshidmini are:

• Full => 10 = 100%
• High => 8 = 100%
• Medium => 5 = 62 %
• Low => 2 = 25%
• Dying => 1 = 12%

I propose Full, High and Medium to be changed to 8, 6 and 4 to represent, respectively, 100%, 75% and 50%

Not being picked up by DS4Windows v2.2.9

Hello Nefarius! Thank you so much for this tool.
Been testing it so far only with DirectInput and RCPS3, with both working great.
Need to still test the PCSX2 mode.

But, with the DS4 mode, the pad is not being detected at all in DS4Windows.
A real DS4 has no problem connecting to it.
But the DS3 with the DS4 mode it's not dice.

Anything (log or else) I have to send you for you to debug?

Thank you.

Two things happening right now:

1. The current DsHidMini driver has a bug in DS4 mode that is mixing buttons/triggers, so you won't be able to use the controller correctly for now.
2. DS3 support on DS4Windows is only working on the Beta Build for now;

If you want to test anyway, download the Beta Build from here and place it at the same folder as the normal DS4windows.exe, then execute the DS4WindowsDebug.exe (make sure the normal DS4windows.exe is not running).

Keep an eye on the DsHidMini release page to see when the fixed version is out

Add shoulder pressure sliders to GPJ mode

As @Kanuan pointed out there's "room" for the two shoulder pressure sliders in GPJ mode on the 1st (Gamepad) top level collection. Adjust packet translation to support them while honouring the axis limits.

Input was inverted (Triangle became Cross)

Hello! After updating to DsHidMini, from scptoolkit on one PC (removed all drivers), I realized the input became weird:
Cross became Triangle (Y became A).

I updated my main PC from Shibari + Fireshock (also removed Fireshock drivers as per instructions), to DsHidMini and found the exact same issue, I tried with 2 original DS3 controllers, and one offbrand (fake) with the same results. Also, on my main PC (desktop), DsHidMini will not work via bluetooth (with the USB Dongle that worked perfectly with Shibari + Fireshock).

Feature Request: Adjustable Idle Timeout Disconnect

Coming from scptoolkit I feel that a slider in the config utility for setting an idle timeout disconnect period would be helpful. Hopefully it wouldn't be too much of a hassle to add

BSOD on sleep and resume

When you connect one or more controllers via Bluetooth, leave it connected and send the PC to sleep, it can cause a crash (BSOD) after resuming from sleep. It's currently under investigation.

As a workaround, make sure to disconnect any wireless device before sending the machine to sleep.

Add support for Navigation Controller

Open tasks

• Add hardware IDs back into INF
• Adjust LED behaviour
  • Only one LED, so make slow flash during charging, solid on when full and rapid flashing when low?
• Check code for possible regressions
  • Should be fine overall since the Navigation Controller responds to the same feature requests and has the same input report length and format, it simply reports less buttons/axes
• Some modes will not behave as expected
  • DS4Windows LED translation will not really do much
  • Nav has no rumble/FFB capabilities AFAIK
  • No need for DirectInput compatibility modes since too little pressure axes

Controller disconnects 5-10s later if reconnected quickly after a disconnect

Steps to reproduce (tested on bluetooth):

• Connect the controller as normal
• Make the controller disconnect (Disconnect by button combo or by changing modes and applying the changes)
• Quickly reconnect the controller
• Wait a few seconds and the controller will disconnect
• After trying to reconnect the controller again, even if done quickly, it will remain connected

Request for LED states reaction to battery level

It would be nice if there was a way for the LEDs to show the battery level on BTH, instead of one LED at a time going from 4 to 1, having all 4 LEDs on for "Full", 3-2-1 on for "High", 2-1 for "Medium" and LED 1 on for "Low" (in particular for DS4 mode with DS4W, so maybe that means DSHM having priority over DS4W for LEDs?). It would be much easier to quickly see the battery level in the dark / from a certain distance / to catch your attention when it's time to plug.

EDIT: Kirian has already made a modification to implement it in a test version (in DS4W with "Blue" set to 255 instead of 0, the "Red" slider moves across the 4 LED states). In my humble opinion this is an elegant solution already as it doesn't interfere at all with existing color values / LED states translations.

Still says that there is a newer version available