Bits and bobs from the SC2 fork

README.md

@@ -12,9 +12,10 @@ User-mode driver, mapper and GTK3 based GUI for Steam Controller, DS4 and many o
 
 ## Features
 - Allows to setup, configure and use the Steam Controller without ever launching Steam
-- Connect multiple controllers at the same time
+- Connect multiple controllers at the same time, each with its own remembered profile
 - Supports profiles switchable in GUI or with controller button
 - Stick, Pads and Gyroscope input
+- Steam Controller 2 (2026) support, including its capacitive stick-touch and grip sensors — bind actions to them directly, or use them as conditions in mode-shift combinations
 - Haptic Feedback and in-game Rumble support
 - OSD, Menus, On-Screen Keyboard for desktop *and* in games.
 - Automatic profile switching based on active window.
@@ -23,6 +24,50 @@ User-mode driver, mapper and GTK3 based GUI for Steam Controller, DS4 and many o
 
 Based on [Standalone Steam Controller Driver](https://github.com/ynsta/steamcontroller) by [Ynsta](https://github.com/ynsta).
 
+## Using multiple controllers
+
+SC Controller can drive several controllers at once — Steam Controllers (v1 and
+v2), a DualShock 4 and others can all be connected together.
+
+- **One window, two bars: pick the controller, then its profile.** Just connect
+  them: a controller-selector bar lists every connected controller (by type,
+  numbered when you have more than one of the same model) together with its
+  current profile; choosing one shows it on the big controller image, and a
+  second bar sets that controller's profile. There is no separate window per
+  device. The controller that connected *first* is the primary one — it is the
+  one drawn by default and the target when a command (a menu, the OSD) does not
+  name a specific controller.
+- **Each controller keeps its own profile.** Selecting a controller and setting
+  a profile applies only to that controller. The choice is remembered and
+  restored automatically the next time that controller connects, so you do not
+  have to re-pick it every session.
+- **Disconnecting is safe.** Turning one controller off (or letting it go idle)
+  leaves the window and the other controllers untouched; when it comes back it
+  returns to its remembered profile.
+
+![SC Controller with three controllers connected](docs/multiple-controllers.jpg?raw=true)
+
+*Two Steam Controller v1s and a Steam Controller v2 connected at once: the
+selector at the top lists each controller — numbered when there are duplicates —
+alongside its current profile.*
+
+### Telling controllers apart
+
+How a controller is identified — and therefore which remembered profile and
+per-controller settings it gets — is governed by **Use Serial Numbers to
+Identify Controllers** in *Settings*:
+
+- **Off (default):** controllers are identified by connection order (first
+  connected, second connected, …). This is simplest for a fixed setup, but if
+  you change which controller powers on first they will swap profiles.
+- **On:** each controller is identified by its own hardware serial number, so
+  its profile and settings follow the physical device no matter what order
+  things connect in.
+
+Turn this **on** when you regularly use more than one controller — especially
+two of the same model, such as two Steam Controllers — and want each to reliably
+keep its own profile.
+
 ## Like what I'm doing?
 
 You can check out the ways to donate on [my website](https://rys.rs/donate), or just go straight to my [Ko-Fi](https://ko-fi.com/martinrys).
@@ -40,6 +85,23 @@ Linux:
   - **Void Linux:** Packaged as [sc-controller](https://github.com/void-linux/void-packages/blob/master/srcpkgs/sc-controller/template) - Run `xbps-install -S sc-controller` in a terminal, points to archived Ryochan7's fork at the time of writing
   - **Others:** You can attempt to use one of the AppImages (try all, AppImages built on older distributions tend to work better), or a package meant for your parent distribution if applicable. Flatpak is planned.
 
+### AppImage: install the udev rules
+
+The AppImage is self-contained but **cannot install the udev rules** it needs (those live in a system directory). Without them your user can't access the controller and SC Controller can't create the virtual gamepad (`/dev/uinput`), so a detected controller appears to "do nothing". Distro packages install these rules for you; **AppImage users must do it once, by hand:**
+
+1. Download `69-sc-controller.rules` from the [latest release](https://github.com/Patola/sc-controller-cc/releases/latest).
+2. Copy it into place — this needs `sudo`:
+   ```sh
+   sudo cp 69-sc-controller.rules /etc/udev/rules.d/69-sc-controller.rules
+   ```
+3. Reload and re-apply the rules:
+   ```sh
+   sudo udevadm control --reload-rules && sudo udevadm trigger
+   ```
+4. Unplug and replug the controller (or its wireless dongle) — or reboot.
+
+Only the AppImage needs this; the Arch and other distro packages already ship these rules. **The Steam Deck doesn't need it either** — SteamOS already ships udev rules for Steam devices, so the AppImage works out of the box there.
+
 Windows:
   - It should be possible to get it running as per the [wiki](https://github.com/C0rn3j/sc-controller/wiki/Running-SC-Controller-on-Windows), but this is untested and might be broken, report a bug if so
 
@@ -80,3 +142,32 @@ docker build -o build-output --build-arg BASE_CODENAME=noble .
   - Optionally checkout a branch or a tag, like `main`(default) or `v0.6.2`
   - Execute `./run.sh`, this automatically builds the project into a venv called `.venv`, activates it and runs sc-controller, which in turn runs scc-daemon if one does not run already
   - If you are debugging an issue, running `./run.sh daemon` first will launch the daemon in debug mode, allowing you to launch sc-controller in another terminal with `./run.sh` - note that sc-controller launched via `run.sh` always runs in debug mode too.
+
+### Regenerating controller artwork (for contributors)
+
+Some SVG assets under `images/` are **generated** from source drawings by scripts
+in `tools/`, so edit the source and rerun the script rather than hand-editing the
+committed output. All scripts run from the repository root and optimise their
+output with [`svgo`](https://github.com/svg/svgo) when it is on `PATH` (optional;
+without it the SVGs are just left un-minified). The `svgo` config
+(`tools/svgo.config.js`) deliberately preserves the element ids, `<rect>`
+geometry, `viewBox` and `display:none` layers that the GUI relies on.
+
+- **`tools/gen_sc2_image.py`** — builds the Steam Controller v2 GUI artwork
+  (`images/controller-images/sc2.svg`, the face-button glyphs and side-panel
+  icons) from the traced sources in `tools/` (`sc2-source.svg`, `sc2-assets/`).
+
+- **`tools/gen_binding_display.py`** — builds the per-controller *Display Current
+  Bindings* templates in `images/binding-display/<gui-background>.svg`. Instead of
+  a hand-drawn asset per controller, it derives each template straight from that
+  controller's GUI drawing (`images/controller-images/<name>.svg`): it scales the
+  drawing into the OSD canvas, recolours it into the binding-display palette
+  (green outlines over two greys on a dark backdrop) and drops a marker ring at
+  each control's `AREA_*` anchor so the binding boxes can draw connector lines to
+  them. The OSD then picks the file up automatically via the controller's gui
+  `background` name (see `scc/osd/binding_display.py`, `_resolve_image`).
+
+  To add a controller: give it an entry in the script's `CONTROLLERS` table (its
+  source drawing + which `AREA_*` anchors each binding box points at) and a
+  matching box layout in `LAYOUTS` in `scc/osd/binding_display.py`, then rerun the
+  script. Controllers that share a physical control set can share a layout.

TODO.md

@@ -1,7 +1,135 @@
 List of (possibly) planned features in no particular order:
 
+- Selectable output device: virtual Xbox (today's default), virtual DS4/DS5,
+  or NO virtual controller at all. The current "Xbox 360 pad" is just a
+  generic uinput device wearing an X360 identity defined entirely in
+  config["output"] (scc/config.py: vendor/product/name/buttons/axes), so the
+  architecture already treats identity as data. Three tiers of work:
+    - no-controller mode (keyboard+mouse only) ALREADY EXISTS as the
+      undocumented SCC_NOGAMEPAD env var (scc/mapper.py create_gamepad);
+      promote it to a config key + GUI toggle (trivial), or per-profile
+      (moderate: create/destroy the uinput gamepad on profile switch).
+      Essential for games that refuse mouse/keyboard input while any
+      controller is detected;
+    - evdev-level DS4/DS5 identity presets (Sony VID/PID + the button/axis
+      layout SDL's gamecontrollerdb expects on the classic path): preset
+      table + GUI dropdown; gives PlayStation glyphs in most games, but no
+      gyro/touchpad/lightbar (those ride on hidraw, which uinput cannot
+      fake; SDL HIDAPI just falls back to evdev);
+    - faithful DS4/DS5 emulation via /dev/uhid: present a real HID device so
+      the kernel's hid-playstation binds and exposes motion/touchpad nodes
+      -> native in-game gyro from ANY supported controller. Big: a uhid
+      backend beside uinput, authentic report descriptors/streams, a udev
+      rule for /dev/uhid. Prior art exists (fake-DS4-over-uhid projects).
+
+- DualShock 4 / DualSense (ds4/ds5) polish. The HID driver is now functional
+  (mapper rstick/dpad guards, touchpad coordinate scaling + click highlight), but
+  rough edges remain:
+    - the two analog sticks are asymmetric in Input Test -- the left and right
+      stick brighten / behave differently from each other;
+    - the input icons drawn around the controller are the generic ones, not the
+      DualShock face symbols (cross / circle / square / triangle);
+    - the DS4 gyro works as relative and absolute (host-side euler integration in
+      _step_orientation, verified on hardware) but the absolute path is gyro-only,
+      so it DRIFTS and gimbals on large combined rotations. The clean next step is
+      accelerometer drift-correction: fuse gyro + accel (complementary filter) to
+      pin pitch/roll to the gravity vector -- the raw accel is still in q1-q3 right
+      after decode, before _step_orientation overwrites them (yaw has no absolute
+      reference without a magnetometer, so it drifts inherently);
+    - gyro -> MOUSE routes to the stick instead: an Axes/Rels IntEnum value
+      collision (ABS_X == REL_X) makes a mouse axis serialize/round-trip as a stick
+      axis. The gyro editor labels + chooser display are fixed, but the save/reload
+      path still needs a proper Axes-vs-Rels disambiguation; use gamepad axes for
+      gyro meanwhile;
+    - no rumble: neither DS4Controller nor DS4HidRawController drives the pad (the
+      DS5 driver does) -- port the DS5/kernel output report; over Bluetooth the
+      DS4HidRawController is input-only, so rumble + lightbar there need output
+      reports with the BT CRC32 wrapper (mirror DS5HidRawController);
+    - the lightbar LED is not driven (no DS4-specific set_led);
+    - DS5 is UNVERIFIED (no DualSense hardware here): its HID touchpad scaling was
+      added by analogy to the DS4 (DualSense pad assumed 1920x1080) and not tested;
+      the DS5HidRawController touchpad is still unscaled and stores cpad as unsigned
+      c_uint16, which can't hold the signed scaled range -- it needs a field type
+      change as well as scaling.
 - Multiple on-screen menus (and possibly keyboards) when using multiple controllers
 - Injecting emulated xbox controller into wine
+- mnuImage right-click "change background" menu has no `sc2` entry (the v2
+  image is selected automatically via sc2.config.json `gui.background`, but
+  it can't be picked manually from that menu yet).
+- Custom small (24px) controller icons per supported controller. Today only the
+  Steam Controller v1 (sc-*) and v2 (sc2-*) have bespoke top-down glyphs; every
+  other type (deck, ds4, ds5, evdev, hid, scbt, fake) reuses the same generic
+  silhouette, just recolored. Draw a distinct glyph per type so each controller
+  is recognisable at a glance. The v2 glyph could also be refined further (its
+  trackpads are necessarily small at 24px).
+- Steam Controller v1 GET_SERIAL reliability (nicety). The flaky v1 serial read
+  is now handled gracefully - usb.py retries a stalled control request instead of
+  tearing the dongle down, and sc_dongle falls back to a generated id if it never
+  reads - so multiple v1s with "Use Serial Numbers" on are detected reliably.
+  Remaining nicety: investigate *why* GET_SERIAL stalls, so a v1 always ends up
+  with its real serial (today a persistent stall yields a positional id instead).
+- Continuous "HD rumble" for the Steam Controller v2 (and v1/Deck). The SC pads
+  are LRA voice-coil actuators, not ERM spin-motors. We already drive single
+  pulses (v1: FEEDBACK report 0x8F; v2: interrupt-OUT report 0x82, effect 0x01 =
+  one click) which suit pad/scroll detents but NOT sustained, amplitude/
+  frequency-modulated game rumble. Gap: the v2's continuous-rumble report is
+  unknown (see sc2.py feedback(): "sustained game rumble may need another report,
+  not yet found"); the v2 uses its own report scheme (interrupt-OUT 0x82),
+  distinct from the Deck's feature-report commands, so it needs confirming for
+  the v2 specifically. Approach (do NOT brute-force the HID space by trial and
+  error - a wrong report just does nothing and gives no signal):
+    1. Read the canonical implementations: SDL's hidapi Steam driver
+       (SDL_hidapi_steam.c / SDL_hidapi_steamdeck.c - ID_TRIGGER_RUMBLE_CMD plus
+       the left/right gain "magic numbers") and the Linux kernel
+       drivers/hid/hid-steam.c (FF play_effect, derived from SDL's Deck code).
+    2. Check first whether SDL3 already rumbles the v2 by its VID/PID - if so,
+       its source *is* the v2 report format and no capture is needed.
+    3. Otherwise capture ground truth: run Steam Input on the v2, trigger rumble
+       (Steam's controller rumble test, or a rumbling game) and capture the USB
+       OUTPUT reports with usbmon + Wireshark; decode the continuous-rumble
+       report Steam actually sends.
+    4. Replicate it in sc2.py feedback() and diff the emitted bytes against the
+       capture to confirm.
+    5. Map the emulated gamepad's FF_RUMBLE strong/weak magnitudes to the LRA's
+       amplitude/frequency/gain and tune for feel (LRA != ERM, so a curve is
+       needed).
+  Plumbing already exists (emulated gamepad FF -> controller.feedback()); the
+  missing piece is the v2 continuous-rumble report itself. Refs: SDL hidapi steam
+  driver, kernel hid-steam.c, and Alice Mikhaylenko's "Steam Deck, HID, and
+  libmanette adventures" writeup.
+- Deck OSD menu fixes. (a) "Display Current Bindings..." and "Run Program..."
+  ship disabled in the menu settings; once enabled they appear in the OSD, but
+  selecting them does nothing - their shell() actions (scc-osd-show-bindings,
+  scc-osd-launcher) don't actually run/work on the Deck. Make them functional.
+  (b) Remove "Turn Controller OFF" from the Deck's OSD menu - the Deck's
+  built-in controller can't be powered off (today it shows and does nothing).
+  Entries defined in scc/gui/global_settings.py (~L45-58, e.g.
+  "Turn Controller OFF" -> osd(turnoff())); menu data in
+  default_menus/Default.menu.
+- Generalize the OSD "Turn Controller OFF" hiding. It's currently hidden only
+  for the Deck's built-in controls (controller type == "deck", checked in
+  scc/osd/menu.py against the --controller-type the daemon passes). Replace that
+  hardcoded type check with a per-controller capability (a ControllerFlags bit or
+  a controller.can_turnoff()) so any controller that can't be powered off
+  remotely hides the entry, not just the Deck.
+- Deck tray/status icon not visible. On the Steam Deck the status (tray) icon
+  doesn't appear even with the option enabled - works on desktop now that
+  libdbusmenu is bundled, so this is a Deck/gamescope SNI-tray-host issue to
+  investigate.
+- Rebrand the AppImage desktop app-id. app_info.id in AppImageBuilder.yml /
+  AppImageBuilder.debian.yml is still org.c0rn3j.sc-controller (upstream), so the
+  installed .desktop carries the upstream id, and the after_bundle step symlinks
+  it as org.c0rn3j.sc-controller.desktop. Switch both to org.patola.sc-controller-cc
+  once the fork is stable and we have committed/PR'd to upstream.
+- Replace the last deprecated GTK stock-icon calls. macro_editor.py (the
+  up/down/delete buttons) and modeshift_editor.py (the clear button) still call
+  `Gtk.Image.new_from_stock("gtk-go-up" / "gtk-go-down" / "gtk-delete", ...)`.
+  They render today (GTK maps the stock id to an icon internally) but the stock
+  API is deprecated; move them to `Gtk.Image.new_from_icon_name` with freedesktop
+  names (go-up / go-down / edit-delete, or the -symbolic variants - all present in
+  Adwaita/Breeze). Same class as the profile_switcher.py save/edit buttons, which
+  were actively blank because `new_from_icon_name` was handed the stock ids
+  "gtk-save"/"gtk-edit" (now document-save / document-edit).
 
 Hard stuff:
 - Injecting emulated xbox controller into PlayOnLinux
@@ -10,7 +138,22 @@ Very hard stuff:
 - Visual feedback in binding editor ( [what this guy says](https://www.reddit.com/r/linux_gaming/comments/5pcdmr/sc_controller_use_steam_controller_without_steam/dcqpvf4/) )
 
 **Done** stuff:
+- "Act on release" (inverted button): a general InvertedButtonModifier plus a
+  checkbox in the button action editor (next to Toggle/Repeat) that fires a
+  binding on *release* instead of press - for always-on sensors like the
+  capacitive grips. Round-trips with the Custom Action `inverted(...)` token.
+- Dedicated v2 controller artwork: traced SVG (tools/sc2-source.svg) wired by
+  tools/gen_sc2_image.py into controller-images/sc2.svg + v2 face-overlay
+  glyphs (button-images/sc2_*.svg, lifted from the drawn symbols so the face
+  buttons are blank in the art -> no duplication, monochrome ABXY, round Steam,
+  single dots) + v2 side-panel icons (images/sc2/*.svg, per-controller override
+  added in app.apply_gui_config_buttons). Control-name ids on sticks/pads/dpad/
+  bumpers + grip-touch shapes so everything highlights on hover; darker body
+  (#b8b8b8). sc2.config.json points at it all. Replaces the borrowed Deck image.
 - Multicontroller support
+- Per-controller profile memory: each controller's profile is remembered by id
+  (config["controllers"][id]["profile"]) and restored on (re)connect - follows
+  the physical device with "Use Serial Numbers" on, per-slot otherwise.
 - Configurable gamepad type (e.g. 4 axes and 16 buttons)
 - Steam Profile import
 - Radial Menu for the Joystick/Trackpad

docs/actions.md

@@ -325,6 +325,14 @@ A button whenever physical button is pressed.
 #### <a name="released"></a> released(action)
 Creates action that occurs for brief moment when button is released.
 
+#### <a name="inverted"></a> inverted(action)
+Acts on release: swaps press and release, so the wrapped action is held while
+the physical button is NOT pressed and released while it is. Meant for
+always-on sensors such as the capacitive handle grips, which read "on" the
+whole time the controller is held - inverting them fires the action when you
+let go. Unlike `pressed`/`released`, which emit a momentary tap, this is a
+true held inversion of the button state.
+
 #### <a name="touched"></a> pressed(action)
 Creates action that occurs for brief moment when finger touches pad.
 

glade/action_editor.glade

@@ -161,7 +161,6 @@
     <property name="destroy-with-parent">True</property>
     <property name="type-hint">dialog</property>
     <signal name="destroy" handler="on_Dialog_destroy" swapped="no"/>
-    <signal name="key-press-event" handler="on_Dialog_key_press_event" swapped="no"/>
     <child>
       <!-- n-columns=3 n-rows=7 -->
       <object class="GtkGrid" id="grEditor">