gyro issues from flaming-couches

[Patola]

@flaming-couches I thought it would be better to replicate your gyro issues here, so it can be treated in this repository and not pollute the main sc-controller bug report.

All what is below is originally from @flaming-couches, quoting me:

A final question: is your configuration depending on the grip touch for the axes to work? If so, maybe that is the reason you could not make it work? Using the right trigger or other conventional input to enable the gyro or even letting it always be enabled might be enough for you to re-rest this.

I was initially using grip touches since that's what I'd want ideally for my use case, but I was also using the left trackpad touch during testing which did work where the grip did not. I did re-test the Per-Axis config with the new context the profile you attached, I went over that below.

[Regarding the Tilt suggestions,] as this is not my application, I am trying to be conservative with the changes.
...
So the art changes and features you want - deadzones, maybe a gyro enabler, maybe an act on release etc. - are not planned for the current moment. Maybe in the future, if my patches are accepted and all goes well.

Fair enough - it's not a very high priority to me since I don't personally have much of a use case for that mode. As someone who strives to be "feature complete" in my own work, I thought I would bring those points to your attention in case you hadn't already noticed them.

Yeah, we come back to the second bug, I couldn't confirm this one. Here it works as expected, maybe if you use this profile I am attaching to the response?

Downloaded your profile and can confirm that it works on my device. Went to investigate my Per Axis configuration further with your updates, and there are definitely some things that are not working as expected. Here's the list of what does and doesn't seem to be working for me, with the associated custom action scripts. To be clear, I am using Steam's "Test Device Inputs" feature on the emulated "xbox 360 controller" as my method of verifying whether or not inputs are being detected, and (in copying your profile) I'm using the right trigger for the enable button with 70% pull:

• For Joysticks when Absolute is not ticked, I'm seeing the expected input responses. mode(RT >= 0.7, gyro(Axes.ABS_RY, Axes.ABS_RX, Axes.ABS_X), None)
• For Joysticks when Absolute is ticked, I'm not seeing any input. mode(RT >= 0.7, gyroabs(Axes.ABS_RY, Axes.ABS_RX, Axes.ABS_X), None)
• For Mouse when Absolute is not ticked, I'm not seeing any input. mode(RT >= 0.7, gyro(Rels.REL_Y, Rels.REL_X), None)
• For Mouse when Absolute is ticked, I'm seeing the expected input response (notably, not the inverted input I was observing in the Joystick or Mouse tab). mode(RT >= 0.7, gyroabs(Rels.REL_Y, Rels.REL_X), None)
• For Triggers (which I didn't test earlier) when Absolute is not ticked, I'm seeing the expected input responses, but at a very high sensitivity to the point where slight movements immediately hit the upper deadzone. Granted, I'm not even sure how a relative mode should work with a trigger setup, so maybe this doesn't need to be tampered with, but I thought I'd bring it up since it's a valid axis. mode(RT >= 0.7, gyro(Axes.ABS_Z, Axes.ABS_RZ), None)
• For Triggers when Absolute is ticked, I'm not seeing any input. mode(RT >= 0.7, gyroabs(Axes.ABS_Z, Axes.ABS_RZ), None)

Hopefully that clears up what's I'm seeing on my end - If you're not observing the same thing with those configurations I might have a different problem to look into.

[flaming-couches]

Somehow missed that I was pinged here and just saw it today. Thanks for keeping me in the loop.

[Patola]

You're welcome. Look, I have had personal issues that made me briefly pause development. But I've made some still uncommitted progress and I think I will be able to get the improved new build tonight. I will ping you here once I get it done.

[Patola]

@flaming-couches I had health issues that took me out for a few but I am back and focused on solving your issues. I apologize for the delay.

[Patola]

@flaming-couches there's a new release for you to try. Hopefully it will fix all your reported bugs. https://github.com/Patola/sc-controller-cc/releases/tag/v0.6.0.6

[flaming-couches]

@Patola Sat down to quickly test the new version on my SC2 tonight. Still encountering the same issues as of the last time I tested on v0.6.0.5. Since the full list of issues and which ones I'm still experiencing has gotten a bit unclear at this point, here's the original list I reported, with patched issues as of v0.6.0.6 stricken through:

1. Attempting to select one of the grip sensors as the gyro enable button doesn't work - gyro just remains off even when the grip sensor is activated. Confirmed this was not an error with the grip sensor input itself, as it passes bound inputs to other programs. Haven't tested every button to check if there are other inputs this applies to, but touching the trackpads or ABXY buttons does work so it's not a problem across the whole controller.

Fully fixed.

2. When using the "Per Axis" action type, Mouse axes don't work at all (although you can select them now, contrary to v6.0.3). It does work under "Joystick or Mouse" and I was able to get a custom action configured using them, so it seems to just be a misinterpretation between the GUI and the [script command?]

While this one has been mostly fixed, a couple issues still remain:

1. The three modes for mouse controls in the "Joystick or Mouse" Tab (Desktop, Camera, Emulate Stick) all function more or less identically, with the mouse position being correlated to gyro angle (roughly, don't know the technicalities of that lol). I would expect at least one of these modes to correlate gyro angle with mouse velocity instead (I think). Whether this is an intended feature or not, I don't know - I feel like there are some use cases for it, at any rate.
2. As quoted from me in the OP above: in "Per Axis," binding gyro to mouse axes doesn't produce input if Absolute is not ticked. As with 1), I think I would expect to see that equate gyro angle to mouse velocity, as with point 1 here?

3. Mouse inputs under the "Joystick or Mouse" action type are inverted on the Y axis relative to Steam Input. While there is a checkbox to invert it back to normal, this should probably still be fixed to reduce confusion.

Fully Fixed.

4. Absolute values for Joysticks are unresponsive under either "Per Axis" or "Joystick or Mouse". Relative inputs do respond. Absolute axes use gyroabs() instead of gyro() so you might just need to apply whatever you did to fix gyro to gyroabs() as well...?

Still unresolved for me - my list of test scenarios quoted in the OP has not changed here (Although the trigger sensitivity I noted there seems to be fixed, or at least different).

5. "Tilt" action Type doesn't seem to be responding at all, seems to be missing a setting for a Gyro Enable Button in the GUI, and uses a 2015 Steam Controller graphic. Would probably also be useful to include angle deadzones for each axis in that mode.

While the additional suggestions I made here are beyond the scope of this fork (as you noted in previous discussion on this), and the Tilt action category isn't relevant to my use cases so it matters less to me, it still appears to be nonfunctional in the current version. (Tested custom command: tilt(hatdown(Axes.ABS_HAT0Y), hatup(Axes.ABS_HAT0Y), None, None, hatright(Axes.ABS_HAT0X), hatleft(Axes.ABS_HAT0X)))

6. Hard to tell due to absolute joystick axes not working at the moment, but it seems like the Recenter Gyro special action is also nonfunctional at the moment. Probably worth double checking it when more of the above are functional.

This one was ambiguous to begin with and I haven't done further testing on it since the initial report, so I'm going to mark it as resolved here for now since it's less relevant.

That being documented, if there's a discrepancy between my report here and what you're seeing on your end during development and testing, let me know if there's any specific system-related things that could be preventing changes from being applied for some weird reason - or other things I should attempt.

[flaming-couches]

Of note here, in case it's relevant for some reason:
Due to a permissions conflict on my system, I'm not able to update my SC2 firmware via the steam GUI since it enters a disconnect loop whenever I try - I need to do it manually via the steam hardware updater in my terminal. The specific steps I use are documented here.
Steam does say my controller's firmware is up to date following doing this, so I don't see why it would cause an issue, but I suppose there's a small chance it's relevant.

[Patola]

@flaming-couches thank you for such a detailed bug report and also the information about firmware.
As you have done quite a bit of explanation, instead of translating in my own words to Claude (and risk misinterpreting or missing nuances), I sent your report as-is to him. I'm pasting the response below, and you'll see that it ends with a question. I am not too keen on making changes on the semantics of the gyroscope -- that would potentially cascade into everything and break lots of stuff. UPDATE: after examining the way it would be implemented, there's a very low risk of cascading effects.

But before we settle on that, there are some verifications for you to perform. Can you do it so we're well informed on what's happening?

---

The comment on that code is the key: the quaternion is "nonzero only when the gyro is enabled", and an all-zero quaternion converts to exactly 0/0/0. Let me look at how that gets enabled:

Ran 3 commands

Now the separate claim about the three mouse modes:

Ran 8 commands

Found it. Two distinct things here — let me separate them, because one is a code bug I can see and one needs his data.

Ran 6 commands

His four remaining items share one signature, and it's the same one from the original report — which is informative, because my fix for that signature shipped and didn't help him.

Everything that reads orientation is dead; everything that reads rate works

still broken | reads -- | -- #4 absolute joystick (gyroabs → stick) | angles q1–q3 #2.2 Per-Axis mouse, Absolute unticked (lean-to-turn) | angles q1–q3 #5 Tilt (actions.py — pyr = (-q1/10430.37, q3/10430.37, -q2/10430.37)) | angles q1–q3 works |   relative joystick, and the laser-pointer mouse | angular rate

My earlier theory for exactly this split was the modeshift gate chattering and wiping the captured reference. That fix is in v0.6.0.6 and he still sees it — so that's now ruled out, and only one candidate remains: on his controller the angles are literally zero.

Here's why that's silent. The SC2 gets its angles from the firmware-fused quaternion, converted in sc2.py:250. An all-zero quaternion converts to exactly zero — atan2(0, 1) = 0, asin(0) = 0 — with no error and no warning. Downstream, gyroabs captures a reference of 0, diffs 0 against 0 forever, and emits nothing. Tilt never crosses its threshold. Lean-to-turn measures no lean.

And the reason his controller could differ from yours is sitting in the driver as a known gap:

def set_gyro_enabled(self, enabled: bool) -> None:
    self._enable_gyros = enabled
    # TODO: which 0x87 CONFIGURE register enables the IMU?

We never enable the SC2's IMU. We inherit whatever state the controller was left in — by Steam, or by its last power cycle. His raw rates clearly stream (relative gyro works), but the fused quaternion may not be running. That's exactly the kind of per-controller state difference that would make it work on your desk and not his.

One command settles it. The SC2 already has the calibration dump, and it prints rates and angles side by side:

SCC_GYRO_CALIB=1 ./sc-controller-cc-0.6.0.6-jammy-x86_64.AppImage daemon debug

(kill any running daemon first; the AppImage forwards daemon debug through to scc-daemon). Then rotate the controller and read the IMU-CALIB lines:

IMU-CALIB  accel unit=(...) |a|=... | rates=( 1834   -12     3) | euler deg  pitch=  47.2 yaw=  -0.2 roll=   0.1

If rates move but the euler columns stay at 0.0, it's confirmed and the fix is to find the CONFIGURE register that turns the fusion on — real protocol work, but a clear target. If the euler columns do move, my diagnosis is wrong and I'll want the raw log.

He's right about the three mouse modes — and it's worse than he thinks

This one I can confirm from the code without any hardware. From gyro_action.glade:

• Mouse (Desktop) → mouse([YAW|ROLL]), default sensitivity 3.5
• Mouse (Camera) → mouse([YAW|ROLL]), default sensitivity 1.0
• Mouse (Emulate Stick) → gyroabs(Rels.REL_Y, Rels.REL_X)

Desktop and Camera are the same action. Not similar — identical, differing only in a default sensitivity number. And since we redefined Absolute as laser-pointer, Emulate Stick is rate-driven too. So all three really are the same thing at three sensitivities, exactly as he says.

The mode he's asking for — tilt angle → cursor velocity — does exist as gyro(Rels.REL_Y, Rels.REL_X), but that tab never offers it. The only route is Per-Axis with Absolute unticked, which is his #2.2, which is broken for him by the angle problem above. So both halves of his #2 are one story.

My recommendation: change the Emulate Stick row to gyro(Rels.REL_Y, Rels.REL_X). "Emulating a stick" means a held deflection produces continuous movement — that is lean-to-turn, so the current binding contradicts its own label. It also makes the three modes genuinely distinct and gives him the mode he wants through the GUI. Loading is unaffected: set_action matches REL_Y/REL_X for any GyroAction subclass, so old profiles still show as Emulate Stick.

That's a semantics change to the absolute/relative split you and I settled on, so I'm not making it unilaterally. Want it?

[flaming-couches]

Took me a minute to interpret what I needed to do, since I'm not diving into the code myself here, but I believe I've gotten the info requested.
In short, claude was right in that my accel columns are tracking but the euler columns are reading 0. In case there's caveats I missed, I detailed the full process I conducted to get that info below:

1. Made sure no background daemons for the app were running by scanning processes with the following command, and killing anything found:

ps axu | grep scc

2. Ran the command provided by Claude in the AppImage's directory, with my SC2 connected (both via puck and USB, in separate tests) and checked the columns while rotating the controller:

SCC_GYRO_CALIB=1 ./sc-controller-cc-0.6.0.6-jammy-x86_64.AppImage daemon debug

While running the command, I also noticed that several events had permissions denied. I don't know if that's normal or not since this is my first time seeing these logs, but in case it's helpful I copied the full startup log prior to the IMU-CALIB lines at the end of this post (replacing my home directory with ~ for privacy). To cover my bases here, I also tried running the AppImage without arguments from the terminal as root to see if that would change anything (it did not, other than breaking the appearance for icons in the app lol).

...That said, I'm not sure what I need to do with this information, if anything. It sounds like it's mostly things on your end? If permissions being denied as noted below isn't normal, it might be more complicated but I guess you can let me know if there's anything else I need to do.

$ SCC_GYRO_CALIB=1 ./sc-controller-cc-0.6.0.6-jammy-x86_64.AppImage daemon debug
D SCCDaemon     Starting SCCDaemon...
D SCCDaemon     Initializing drivers...
W SCCDaemon     Skipping disabled driver 'ds4drv'
W SCCDaemon     Skipping disabled driver 'ds5drv'
W SCCDaemon     Skipping disabled driver 'fake'
W SCCDaemon     Skipping disabled driver 'remotepad'
D USB           Registered USB driver for 28de:1304
D USB           Registered USB driver for 28de:1302
D USB           Registered USB driver for 28de:1102
D USB           Registered USB driver for 28de:1142
D USB           Registered USB driver for 28de:1205
D Mapper        Creating virtual devices
D Mapper        Keyboard: <scc.uinput.Keyboard object at 0x70564a4c7370>
D Mapper        Mouse:    <scc.uinput.Mouse object at 0x70564a4c7d30>
D Mapper        Gamepad:  <scc.uinput.UInput object at 0x70564a4c6f20>
D SCCDaemon     Created control socket ~/.config/scc/daemon.socket
D SCCDaemon     Connected to XServer :0
D evdev         Skipping evdev node /dev/input/event1: [Errno 13] Permission denied: '/dev/input/event1'
D evdev         Skipping evdev node /dev/input/event0: [Errno 13] Permission denied: '/dev/input/event0'
D USB           USB device added: 28de:1304
D root          TODO: Hardcoded 1s sleep!
D evdev         Skipping evdev node /dev/input/event9: [Errno 13] Permission denied: '/dev/input/event9'
D evdev         Skipping evdev node /dev/input/event19: [Errno 13] Permission denied: '/dev/input/event19'
D evdev         Skipping evdev node /dev/input/event20: [Errno 13] Permission denied: '/dev/input/event20'
D evdev         Skipping evdev node /dev/input/event21: [Errno 13] Permission denied: '/dev/input/event21'
D evdev         Skipping evdev node /dev/input/event22: [Errno 13] Permission denied: '/dev/input/event22'
D asyncio       Using selector: EpollSelector
D evdev         Skipping evdev node /dev/input/event23: [Errno 13] Permission denied: '/dev/input/event23'
D evdev         Skipping evdev node /dev/input/event24: [Errno 13] Permission denied: '/dev/input/event24'
D evdev         Skipping evdev node /dev/input/event25: [Errno 13] Permission denied: '/dev/input/event25'
D evdev         Skipping evdev node /dev/input/event26: [Errno 13] Permission denied: '/dev/input/event26'
D evdev         Skipping evdev node /dev/input/event27: [Errno 13] Permission denied: '/dev/input/event27'
D evdev         Skipping evdev node /dev/input/event28: [Errno 13] Permission denied: '/dev/input/event28'
D evdev         Skipping evdev node /dev/input/event29: [Errno 13] Permission denied: '/dev/input/event29'
D evdev         Skipping evdev node /dev/input/event18: [Errno 13] Permission denied: '/dev/input/event18'
D evdev         Skipping evdev node /dev/input/event17: [Errno 13] Permission denied: '/dev/input/event17'
D evdev         Skipping evdev node /dev/input/event2: [Errno 13] Permission denied: '/dev/input/event2'
D evdev         Skipping evdev node /dev/input/event3: [Errno 13] Permission denied: '/dev/input/event3'
D evdev         Skipping evdev node /dev/input/event5: [Errno 13] Permission denied: '/dev/input/event5'
D evdev         Skipping evdev node /dev/input/event6: [Errno 13] Permission denied: '/dev/input/event6'
I SC2           IMU-CALIB  accel unit=( 0.01  0.02  1.00) |a|= 16396  |  rates=(     0     -1      1)  |  euler deg  pitch=   0.0 yaw=   0.0 roll=   0.0
D SCCDaemon     Loaded remembered profile 'Gyro Test' for 1:10
D SCCDaemon     Assigned default_mapper to <SC2 1:10>
D SCCDaemon     Controller added: <SC2 1:10>
Gtk-Message: 23:35:38.189: Failed to load module "xapp-gtk3-module"
D OSD DaemonCtrl    Connected to daemon, version 0.6.0.6
D OSD DaemonCtrl    Daemon reported profile change for 1:10: ~/.config/scc/profiles/Gyro Test.sccprofile
D OSD DaemonCtrl    Daemon is ready.
I SCCDaemon     Registered scc-osd-daemon
I OSD osd.daemon    Sucessfully registered as scc-osd-daemon

[Patola]

Thank you. I am preparing a pre-release and will do some testing for myself, then I will make the build available.

---

Root cause of the problem

The SC2's config block is (register, value16-LE) triplets, and the one captured from Steam starts 30 18 00. Register 0x30 is the IMU-stream bitmask — the v1 driver documents the bits, at the identical position right after its own 0x30:

# scc/drivers/sc_dongle.py:457
# 0x10 (Gyro) | 0x08 (Accel) | 0x04 (Quat)
0x1C if self._enable_gyros else 0,

So 0x18 = 0x10 | 0x08 = rates and accel, but not the fused quaternion. And parse_input derives the euler angles the SC2 reports through EUREL_GYROS from that quaternion. An all-zero quaternion converts to exactly zero — atan2(0, 1) = 0, asin(0) = 0 — silently, no error. Every orientation-based binding sat at neutral forever while the rate-based ones worked perfectly. That is his entire remaining list: #4, #2.2 and #5.

And this is why it didn't work on your pad. Nothing in the driver ever wrote that register — set_gyro_enabled() was a no-op with # TODO: which 0x87 CONFIGURE register enables the IMU?. We inherited whatever state the controller was left in, so a pad that Steam had already switched the quaternion on kept working, and one that hadn't never started. Same binary, two behaviours, no way to tell from the code.

Fix

configure() now builds register 0x30 from the gyro state, and set_gyro_enabled() actually sends it:

gyro off -> 0x18
gyro on  -> 0x1C   (v1 driver sends 0x1C)

Independently derived, lands on the v1's exact value. Rates and accel stay on unconditionally (identical to the previous state) so nothing that currently works can regress; only the quaternion bit is new.