ds4windowsapp/ds4windows

1. Overall shape

- DS4Windows is a Windows desktop application built on .NET 8 / WPF.

- It is primarily an input remapping and controller-emulation engine: physical gamepads come in, profiles/mappings are applied, and virtual controllers / keyboard-mouse / macros go out.

2. Top-level runtime entry

- Startup is centered in App.xaml.cs, Program.cs, and StartupMethods.cs.

- MainWindow is the main shell, with a tray icon path and several auxiliary windows for configuration, calibration, and update flow.

- ArgumentParser.cs suggests command-line and startup-mode handling, while AutoProfileChecker / AutoProfileHolder and WelcomeDialog support first-run and profile automation.

3. Core control plane

- DS4Control/ControlService.cs is the central orchestrator.

- This layer manages controller slots, connected devices, output-device selection, profile application, logging, and service-level options.

- Supporting classes like ControllerSlotManager, OutputSlotManager, OutputSlotPersist, and ControllerSlotManager indicate that controllers are tracked as logical slots independent of the specific physical device.

4. Input device abstraction

- DS4Library contains the low-level controller models and HID-facing types.

- Supported input families include DualShock 4, DualSense, Switch Pro, JoyCon, and DS3.

- HidLibrary wraps raw Windows HID access, so the app can read reports from USB/Bluetooth-connected controllers without relying on a game engine or higher-level framework.

5. Output and emulation layer

- DS4Control/DS4OutDevice.cs and the DS4OutDevices subfolder define output targets and per-device variants.

- The app can emulate or expose different virtual controller forms, with Xbox360OutDevice and the ViGEm-related wrappers indicating the main virtual-gamepad path.

- OutputKBM provides keyboard/mouse output via either SendInput or FakerInput, abstracted behind VirtualKBMFactory and related mapping classes.

6. Input-to-output mapping pipeline

- Mapping.cs, PresetOption.cs, MacroParser.cs, InputMethods.cs, and stick/curve helpers define how raw controller state becomes actions.

- Actions include button remaps, stick transforms, mouse movement, wheel events, touchpad behavior, lightbar effects, and macros.

- Debouncing, drift handling, and stick curves are first-class concerns; the README explicitly calls out switch debouncing and drift-related features.

7. Profiles, settings, and persistence

- Configuration is profile-driven, with ProfileEntity, ProfileList, and the XML DTOs under DS4Control/DTOXml.

- These DTOs show the persistence boundary: profiles, app settings, auto-profiles, linked profiles, output-slot state, and per-controller options are serialized/deserialized through a dedicated schema layer.

- ProfileMigration.cs and versioned profile docs imply compatibility handling across releases.

8. User interface and presentation model

- DS4Forms is a large WPF UI layer containing windows, user controls, and editor dialogs for nearly every feature: profile editing, bindings, calibration, special actions, updater, auto-profiles, and logs.

- ViewModels mirrors those screens with a view-model-per-feature pattern, suggesting MVVM separation between UI and control logic.

- This layer is mostly a presentation boundary; it drives the core service rather than owning device logic itself.

9. Special actions and automation

- DS4Forms/ViewModels/SpecialActions and DS4Control/MacroParser.cs show a discrete automation subsystem.

- Supported actions include launching programs, loading profiles, pressing keys, multi-action buttons, battery checks, and macros.

- UdpServer.cs and the presence of SharpOSC in libs indicate an external control/telemetry integration path, likely for remote or OSC-style interaction.

10. Device utilities and Windows-specific integration

- HidHideAPIDevice.cs, ScpUtil.cs, VJoyFeeder, and NativeMethods indicate Windows-native integration points for driver management and compatibility workarounds.

- The project depends on ViGEmBus for virtual controller emulation and includes bundled native dependencies under libs/x86 and libs/x64.

- FakerInputWrapper and Nefarius.ViGEm.Client are especially important because they define the platform-dependent output mechanisms.

11. Diagnostics, logging, and localization

- Logging is handled through NLog.config plus internal log models like LogItem, LogWriter, LoggerHolder, and StatusLogMsg.

- The app is localized: Translations/Strings.*.resx and Properties/Resources.*.resx show a resource-driven multilingual UI.

- This matters architecturally because much of the UI text and status reporting is not hardcoded.

12. Update/release and repo automation

- GitHub Actions workflows handle duplicate PR/issue management, out-of-scope handling, shipped-fix logic, and release automation.

- ApiDTO/GitHubRelease.cs, Changelog.json, and newest.txt support the app’s update-check/release metadata path.

- The README notes that this fork changes update/version detection to point at this repo’s release source.

13. Tests and quality boundary

- DS4WindowsTests covers profiles, mappings, macro parsing, lightbar macros, settings, and profile migration.

- This test set is focused on the core transformation logic rather than UI rendering, which matches the project’s architecture: most risk sits in profile parsing, mapping correctness, and compatibility behavior.

14. Diagram-friendly boundary summary

- A good architecture diagram should show:

- Physical controllers / HID devices on the left.

- HID input layer + device models in the middle.

- Control service, profiles, mappings, macros, auto-profile logic as the core processing engine.

- Virtual outputs on the right: ViGEm/Xbox-style controller, KBM injection, OSC/UDP, lightbar/rumble feedback.

- WPF UI/view-models as an administrative layer above the core, and persistence/update/logging/native driver dependencies as supporting subsystems.