Steam Controller 2 (2026) driver, Steam Deck support, multi-controller UX, and OSD/GUI fixes

.github/workflows/appimage.yml

@@ -16,7 +16,18 @@ jobs:
             arch: amd64
           - platform: linux/arm64
             arch: arm64
+        # CI builds every base for compatibility coverage / downloadable
+        # artifacts, but releases attach only the most-compatible jammy pair
+        # (Ubuntu 22.04, glibc 2.35 - runs on everything newer: Ubuntu 22.04+,
+        # Debian 12+, Arch, etc.); see the release job's download pattern below.
+        # Add bases here freely - they won't bloat the release.
         base:
+          # jammy stays in the fork even though upstream dropped it: it is the
+          # RELEASE base (glibc 2.35 covers Ubuntu 22.04 LTS onwards).
+          - os: ubuntu
+            codename: jammy
+            pubkey: 871920D1991BC93C
+            recipe: AppImageBuilder.yml
           - os: ubuntu
             codename: noble
             pubkey: 871920D1991BC93C
@@ -122,6 +133,8 @@ jobs:
           #  os: ubuntu-24.04-arm
 
         base:
+          - os: ubuntu
+            codename: jammy
           - os: ubuntu
             codename: noble
           - os: ubuntu
@@ -173,9 +186,21 @@ jobs:
       - name: Download artifacts
         uses: actions/download-artifact@v8
         with:
-          pattern: appimage-*
+          # CI builds all bases, but only the most-compatible jammy AppImages
+          # (one per arch) are attached to the release. Widen this pattern to
+          # ship additional bases.
+          pattern: appimage-jammy-*
           path: assets
           merge-multiple: true
+      # Kept in the fork although upstream dropped it: our releases ship
+      # per-asset .sha256 checksums.
+      - name: Create checksum for release assets
+        shell: bash
+        run: |
+          algo="${SHA_ALGORITHM:-256}"
+          find assets -type f | while read -r asset; do
+            shasum --binary --algorithm "${algo}" "${asset}" >"${asset}.sha${algo}"
+          done
       - name: Upload artifacts to GitHub release
         uses: softprops/action-gh-release@v3
         with:

AppImageBuilder.debian.yml

@@ -17,7 +17,7 @@ script:
 AppDir:
   app_info:
     id: org.c0rn3j.sc-controller
-    name: sc-controller
+    name: sc-controller-cc
     version: "{{APPIMAGE_VERSION}}"
     icon: sc-controller
     exec: usr/bin/python3
@@ -214,4 +214,4 @@ AppDir:
 
 AppImage:
   arch: "{{APPIMAGE_ARCH}}"
-  update-information: "gh-releases-zsync|C0rn3j|sc-controller|latest|sc-controller-*-{{APPIMAGE_APT_DISTRO}}-{{APPIMAGE_ARCH}}.AppImage.zsync"
+  update-information: "gh-releases-zsync|Patola|sc-controller-cc|latest|sc-controller-cc-*-{{APPIMAGE_APT_DISTRO}}-{{APPIMAGE_ARCH}}.AppImage.zsync"

AppImageBuilder.yml

@@ -17,7 +17,7 @@ script:
 AppDir:
   app_info:
     id: org.c0rn3j.sc-controller
-    name: sc-controller
+    name: sc-controller-cc
     version: "{{APPIMAGE_VERSION}}"
     icon: sc-controller
     exec: usr/bin/python3
@@ -207,4 +207,4 @@ AppDir:
 
 AppImage:
   arch: "{{APPIMAGE_ARCH}}"
-  update-information: "gh-releases-zsync|C0rn3j|sc-controller|latest|sc-controller-*-{{APPIMAGE_APT_DISTRO}}-{{APPIMAGE_ARCH}}.AppImage.zsync"
+  update-information: "gh-releases-zsync|Patola|sc-controller-cc|latest|sc-controller-cc-*-{{APPIMAGE_APT_DISTRO}}-{{APPIMAGE_ARCH}}.AppImage.zsync"

Dockerfile

@@ -8,7 +8,12 @@ RUN <<EOR
 	set -eu
 
 	# Workaround for outstanding fix of https://bugs.launchpad.net/ubuntu/+source/python-build/+bug/1992108
+	# (upstream dropped this with jammy support; our releases still build on jammy)
 	. /etc/os-release
+	if [ "${UBUNTU_CODENAME-}" = 'jammy' ]; then
+		echo >>/etc/apt/sources.list.d/jammy-proposed.list 'deb [arch=amd64] http://archive.ubuntu.com/ubuntu/     jammy-proposed universe'
+		echo >>/etc/apt/sources.list.d/jammy-proposed.list 'deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy-proposed universe'
+	fi
 
 	apt-get update
 	export DEBIAN_FRONTEND=noninteractive
@@ -40,8 +45,19 @@ RUN <<EOR
 	python -m venv .env
 	. .env/bin/activate
 	pip install libusb1 pytest vdf
-	python -m pytest tests
-	pip install --prefix "${TARGET}/usr" --no-warn-script-location dist/*.whl
+	# Tests need Python 3.11+, which jammy (3.10) lacks. os-release must be
+	# sourced HERE: each RUN is a fresh shell, so the previous RUN's sourcing
+	# doesn't carry over -- the old unquoted, unset ${UBUNTU_CODENAME} made
+	# this test error out and silently skip the suite on EVERY base.
+	. /etc/os-release
+	if [ "${UBUNTU_CODENAME-}" != 'jammy' ]; then
+		python -m pytest tests
+	fi
+	# --ignore-requires-python: the wheel declares the >=3.11 source-install
+	# floor, but the jammy AppImage bundles jammy's Python 3.10, where the
+	# runtime is deliberately kept working (the enums use the functional
+	# IntEnum API); without the flag pip refuses the install on jammy.
+	pip install --prefix "${TARGET}/usr" --no-warn-script-location --ignore-requires-python dist/*.whl
 
 	# Save version
 	PYTHONPATH=$(find "${TARGET}" -type d -name site-packages) \

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
 
@@ -79,3 +141,32 @@ docker build -o build-output --build-arg BASE_CODENAME=noble .
   - Optionally checkout a branch or a tag, like `python3`(default) or `v0.4.9.8.8`
   - Execute `./run.sh`, this automatically builds the project into a venv called `.env`, 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`
+
+### 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.