Bits and bobs from the SC2 fork

README.md

@@ -41,7 +41,7 @@ User-mode driver, mapper, and GTK 4 based GUI for game controllers, including bu
 
 - Allows to setup, configure and use the Steam Controller (2015 & 2026) without ever launching Steam
 - Emulates the Xbox 360 controller, mouse, trackball and keyboard
-- Connect multiple controllers at the same time
+- Connect multiple controllers at the same time, each with its own remembered profile
 - Supports profiles, switchable in the GUI, or with a controller button
 - Joystick, Touchpad and Gyroscope input
 - Haptic Feedback and in-game Rumble support
@@ -73,6 +73,75 @@ Beware that even when you do use automapper instead of manual assignment, you st
 *Note that there is no automatic discovery of evdev nodes for gyroscope/touchpad, so if your controller has one of those, it currently needs SCC to implement a custom driver for it.*</br>
 *That does mean that devices like Nintendo controllers do not have a working gyroscope, as I do not own any.*
 
+## 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).
@@ -150,6 +219,23 @@ We also have a [Discord](https://discord.gg/d3G7dDJ2G7) available.
 	</tr>
 </table>
 
+### 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.
+
 ## Building the package by yourself
 
 ### Dependencies
@@ -187,6 +273,35 @@ docker build -o build-output --build-arg BASE_CODENAME=noble .
   - 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.
+
 ## AI notice
 
 If you contribute AI-assisted work, please disclose it, make certain you have reviewed it, and ensure that you have tested the changes.