circumspector / ds4windows Goto Github PK

Add an architecture description to the README (what component does what etc.).

This is the biggest legacy beast and the more I read about it the more confused I get so I'll start a fresh rewrite using smaller, dedicated services that all handle their own little responsibilities (device enumeration, state handling, hot-plug, single point of truth etc.).

• Rewrite controller detection and lifecycle handling
• Rewrite DualShock 4 processing
• Rewrite DualSense processing
• Rewrite JoyCons processing
• Rewrite Switch Pro processing
• Rewrite mapping pipeline
• Rewrite emulated output devices pipeline

can't run on windows10 21H2......
crash after run display splash

Another big one but looks very promising!

The native WPF XAML binding in combination with the MVVM pattern is powerful but also very verbose. I've read through samples of ReactiveUI and find many of their approaches very appealing, worth giving it a shot.

Sections in the code that generate user-facing information (except the logging system) should be decorated with the MissingLocalization attribute to find and migrate them to the translation system at a future point.

Replace the horrid verbose XML-bases system to store and retrieve persisted data with a proper serializer.

XML

If we stick to XML (convenient for a more gentle transition phase) I'd highly recommend a robust library like ExtendedXmlSerializer.

• Migrate Actions.xml
• Migrate Auto Profiles.xml
• Migrate ControllerConfigs.xml
• Migrate LinkedProfiles.xml
• Migrate OutputSlots.xml
• Migrate Profiles.xml

JSON

Who doesn't love Json.NET, very harsh on transitioning, although XML to JSON conversion is supported, but may be troublesome with the custom crafted format currently used.

Herp derp

This seems to have broke this week with one of the recent updates. My battery always shows 0% now.

Running 3.2.4

thanks.

OpenTracing has been deprecated in favour of the mighty successor OpenTelemetry, which also incorporates logging events. It also plays nice with .NET Core IoC patterns. OpenTracing would be then obsolete.

Resources

• Getting started
• OpenTelemetry.Exporter.Jaeger

Sony Bluetooth Dongle detection code can be improved. See how its done in Linux kernel driver: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-playstation.c#L2352-L2406

Adopting the TAP model - especially in GUI code paths - would benefit responsiveness and could further reduce the amount of hacks and legacy designs used to keep everything responsive.

Since the exclusive access flag trick doesn't work reliably anymore in years anyway (and will not come back the way Windows nowadays is designed) it should be removed in its entirety. Same goes for HidGuardian, since it is EOL.

SignalR is used in various Microsoft frameworks based on or extending ASP.NET Core so swap out the current Websocket implementation with SignalR (which uses WS under the hood anyway).

Communicating with the JavaScript based BezierCurveEditor can be simplified by delivering it with an integrated web server like EmbedIO.

Currently the Profile Editor (and View Model plus a few supportive types) gets allocated and destroyed every time it is invoked.

Once integration with the new Profile Service is advanced far enough, convert the entire user control into one singleton IoC service to ease memory management and streamline handling injected dependencies.

• ProfileEditor
• ProfileSettingsViewModel
• MappingListViewModel
• SpecialActionsListViewModel

All the controllers that I have used that support SWTICH mode cannot be detected by DS4Windows after overclocking with Hidusbf in SWTICH mode (the output delay display will be particularly high), nor can I use functions such as gyroscope.

After getting familiar with the code to a certain degree of depth a dead-end has been hit. To continue working on breaking changes to benefit progress it's been decided to write a new profile handling logic in parallel to the existing one and gradually migrate all dependant classes over to the new logic. The legacy code and work so far will be kept as it greatly benefits transparent conversions from app version 3 profile schemas to the new system.

A lot will break down this path 🙂

This project is undergoing major rework meaning that at no state there is a guarantee that a build may be in any way useful to an end-user or even able to launch. We know. That's literally what "work in progress" means 🙂 The team doesn't need bug reports as they're simply distracting and no help until the code base has reached a certain maturity level. So kindly hold your fingers still and refrain from wasting the team's time by attempting to get support, through whatever channel, you won't get any and all you do is cause more moderation work none of us needs/wants right now. Please respect that. If you have any questions, simply read this paragraph again until it is understood 🙂

If you are a developer that would like to contribute and join the team, please message @nefarius ❤️

(This seems unrelated to the known issues caused by the ViGEmBus' driver "OutRep flags" limitation and more like an actual issue with how DS4Windows manages lightbar effects)

Bug description

When the "Flash Lightbar at High latency" option is enabled the lightbar is supposed to blink in a red color when the controller's input delay goes above a pre-configured limit, then to revert to the previous active color after the delay returns to below the limit.

If the Lightbar is in Passthru mode and the "red blinking" input delay warning gets activated, the lightbar will properly blink in red while the delay is high, but will then fail to properly "reset" after the warning gets deactivate:

• After the latency warning is over, it will always reset to the profile's hidden "main color" and it remain blinking
  • The color gets reset to the profile's "main color" regardless if a different color was previously defined by a game or app through the passthru function
  • It will only stop blinking/properly reset after a new lightbar command is sent to the controller

Reproducing the bug

Steam will be used in the example to set the lightbar color via the passthru function:

1. On the used DS4Windows' profile
   1. Set profile's normal lightbar color to "Blue", then change its mode to "passthru"
   2. Set the virtual controller to DualShock 4
2. Activate the high latency warning option in DS4Windows' settings
3. Run DS4Windows under a custom .exe name so its virtual DS4 controllers can be detected by it
4. On Steam controller settings:
   1. Activate "PlayStation Configuration Support"
   2. Make Steam change the controller's lightbar to "Green"
5. Cause a latency spike so the high latency warning gets activated

What is the correct behavior

Lightbar should blink in red while the input delay is above the limit, then return to the solid green color set by Steam once it's within the limit again

What is the actual behavior

After the input delay is within limit again the lightbar returns to the "Blue" color and will remain blinking. After some time, Steam may refresh the lightbar color and only then the lightbar will properly reset

The input report processing slowly but steadily leaks memory. Analyze with the profiler and identify and optimize the problematic sections, see

HTTP client calls in e.g. ControllerServiceClient can be simplified by using a named HttpClient instance and configuring the base address of the server once instead of for every route. This also allows to configure retry policies with Polly.

Related to #78

It is currently quite difficult to properly manage the dependency to the ViGEm .NET wrapper and the rest of the code. This issue serves as a reminder to rework the emulation pipeline.

What this is

Over its lifespan of of nearly a decade DS4Windows has seen many contributors, changes, fixes, feature additions and has grown and kept relevant to gamers who'd love more control over their beloved peripherals. Beginning with the PS4 Controller (DualShock 4) it nowadays also supports its successor the PS5 DualSense and even the Nintendo JoyCons. With age and popularity come new challenges. The code has become more powerful, but also more troublesome to maintain and carries a lot of legacy design patterns and restraints from an outdated .NET universe. Here's where we step in.

CircumSpector is a collective of enthusiasts craving to see DS4Windows continued. We attempt to rewrite major sections of the dated code segments to make maintenance and new feature additions fun again. This will take some time and a lot will probably break - intentionally or unintentionally so sooner or later we need a bigger test squad. For now, the issue tracker and discussions remain collaborators only to avoid bug reports for things we already know so we can focus on the code and nothing else.

What this is NOT

As of time of writing we don't strife to be considered the "new maintainers" and dethrone Ryochan7 who's on a well-deserved hiatus from the project for a yet to be known duration (disclaimer: we don't speak on behalf of Ryochan7, we're merely observers as well). Time will tell if Ryochan7 comes back from a vacation and continues working on DS4Windows with help from the members of CircumSpector.

As of Summer 2022 the team behind CircumSpector decided to go their own way forward which resulted in starting a rewrite from scratch and only taking the original DS4Windows sources and concepts as influences but with new fresh ideas in mind. This decision allows DS4Windows to keep evolving using the ideas of the current maintainer and gives us the freedom to shake off any past restrictions and provide a new, exciting remapping solution that everyone likes developing for! As a result, this fork has been detached from the origin repository and an intermediate name "Vapour Input" was chosen to avoid confusion between the two projects.

Hunting down performance bottlenecks with logging or printing debug lines is tedious beyond believe. Introduce a tracer like Jaeger.

• Instrument input reading, transformation and output path
• Make tracing a configurable option

This is a very ambitious task but I may put it on record. I think the app is a great candidate to offload a lot of the global objects handling and singletons to dependency injection.

See for reference.

• Convert form elements (windows, user controls, etc.)
• Convert view models
• Convert profile classes
• Convert mapping classes
• Convert device classes
• Convert supportive types

This will basically deprecate and replace #6 which seems like wasted effort, but MahApps.Metro also offers a ton of custom WPF controls that may even be able to replace the dependency on Extended WPF Toolkit which currently looks out of place due to Adonis styling not covering the custom toolkit controls.

Replacing Adonis UI is quite a swift task anyway, most could be done via simple search & replace actions.

Controls and types used from WPF Toolkit

• IntegerUpDown
• DoubleUpDown
• ColorPicker
• InverseBoolConverter
• ThicknessSideRemovalConverter
• SplitButton
• ButtonChrome
• ButtonSpinner
• WatermarkTextBox
• ColorCanvas
• DecimalUpDown

Get rid of the custom Steam folder mechanism (that is nowadays obsolete anyway due to multiple game libraries being able to co-exist) and use automatic detection like JHolloway.SteamLibrary.

Potentially similar solutions exist for GOG etc.

Hi, I'm not really sure if there will be a test release soon, I've been trying the artifacts without avail but in case this has not been researched/implemented, you can check it out:

https://github.com/asimonf/DS4AudioStreamer

As this is a proof of concept that was being disclosed on GitHub for DualsenseX for any future developments over the Dualsense support. It would be nice to have implementation for the DS4.

The command line processing code is currently very verbose and like a spider web "everywhere". Once #7 has matured far enough, rewrite it in a more maintainable and extendable way.

Big chunks of duplicated native code can be automated away using CsWin32.

Migrate classes

• DS4Windows.Shared.Devices\HID\HidDevice.cs
• DS4Windows.Shared.Devices\Services\HidHideControlService.cs
• Ds4Windows.Shared.Devices.Interfaces\Util\NativeMethods.cs
• DS4Windows.Shared.Devices\Services\HidDeviceEnumeratorService.cs

Remove packages

• PInvoke.SetupApi
• PInvoke.Hid
• PInvoke.Kernel32

Spice UI theming and consistent look up with ease by using Adonis UI.

• Convert all windows to Adonis windows
• Add missing compatible styles to used WPF Toolkit controls that don't match the Adonis theme looks

Reduce dependency to only main binary and signed releases by using NetSparkle.

Introduce PropertyChanged.Fody to get rid of a lot of custom events and duplicated code in MVVM sections by offloading property changed notifications generation to the compiler.

DualSense advanced haptic feedback can be triggered via audio channel sent to it. Actuators are used in this controller not vibration motors like in DS4 and in result it can give better vibration experience to users.

The feature is related to #131 due to the need of sending audio data to controller and compress it with SBC before send via Bluetooth.

Here is demo code that can work for USB use case (without compression): https://gist.github.com/Ohjurot/b0c04dfbd25fb71bc0da50947d313d1b
Related Linux driver code: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-playstation.c (DS_OUTPUT_VALID_FLAG0_COMPATIBLE_VIBRATION shouldn't be set invalid_flag0 as far as I understand).

The packages Microsoft.Toolkit and Microsoft.Toolkit.Mvvm are marked deprecated. Adopt the suggested replacement packages and migrate to them:

<PackageReference Include="CommunityToolkit.Common" Version="8.0.0" />
<PackageReference Include="CommunityToolkit.Mvvm" Version="8.0.0" />

On random application start occasions, a silent crash of the main executable (new and old) can be observed, details in Event Viewer:

Faulting application name: DS4Windows.Client.exe, version: 1.0.0.0, time stamp: 0x6216d2c0
Faulting module name: ntdll.dll, version: 10.0.19041.1566, time stamp: 0x1be73aa8
Exception code: 0xc0000374
Fault offset: 0x00000000000ff249
Faulting process id: 0x243c
Faulting application start time: 0x01d836e39ab10d3b
Faulting application path: D:\Development\GitHub\DS4Windows\DS4Windows.Client\bin\Debug\net6.0-windows10.0.19041.0\DS4Windows.Client.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: cac51fef-f6e5-417d-8131-6ff83453b8ac
Faulting package full name: 
Faulting package-relative application ID: 

This dates quite far back, seems to appear more frequent on Debug than Release builds. Some lingering issue with either unsafe sections or P/Invoke calls. See also.

Further details:

System.AccessViolationException
  HResult=0x80004003
  Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>