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,75 @@ 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.
+
+### PlayStation controllers: turn off Steam's controller support
+
+A DualShock 4 or DualSense **cannot be claimed exclusively over Bluetooth**, and
+this is worth knowing before you conclude something is broken.
+
+Steam Controllers are taken exclusively: SC Controller claims the USB interface,
+which detaches the kernel driver, and nothing else can reach the device. Over
+Bluetooth a DS4/DS5 is reached through `/dev/hidrawN` instead — and hidraw
+allows **several readers at once**. If Steam is running with PlayStation
+controller support enabled, Steam and SC Controller both receive every report
+and both act on it. There is no way for us to lock Steam out.
+
+What that looks like in practice, and it does not look like a conflict:
+
+- the touchpad moves the pointer with an acceleration and glide you never
+  configured, whatever the pad is actually bound to
+- clicking the touchpad produces a mouse button instead of your binding, and
+  rebinding it changes nothing
+- your own bindings *do* work — so the controller seems half-configured rather
+  than contested
+
+Fix it in **Steam → Settings → Controller** by turning off *PlayStation
+Controller Support*. Connecting the pad **by USB** also works, for a different
+reason: claiming the USB interface takes the device away from Steam too.
+
 ## 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 +110,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/macOS:
   - Not planned, the half-finished C rewrite has Windows support but it has been abandoned, see https://github.com/C0rn3j/sc-controller/issues/44 for more info
 
@@ -80,3 +167,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.