ValveSoftware
Controls on the left side of the Deck cease functioning when updating past SteamOS 3.6.4
System Info:
- Steam client version: 1750380802
- SteamOS version: 3.7.10
- Opted into Steam client beta?: No
- Opted into SteamOS beta?: Yes
- Have you checked for updates in Settings > System?: Yes
Ever since updating to 3.7.8, the controls on the left side of my 256GB LCD Steam Deck stopped responding completely. The controller test doesnt even think theyre being used when attempting to use them. All Stable and Beta versions since them have yielded the same result, and I have had to roll back to 3.6.4.
Steps for reproducing this issue:
- Update from 3.6.4 to 3.7.8 or higher
Log File:
Can I double check: The title says the breakage is post 3.6.4 .
Does that mean you've seen it in a 3.6.5+ version, or was the first time you saw it when you booted 3.7.8?
Can I double check: The title says the breakage is post
3.6.4.Does that mean you've seen it in a
3.6.5+version, or was the first time you saw it when you booted3.7.8?
I went straight from 3.6.4 to 3.7.8 on the Stable update channel, so it wouldve been the latter.
Still looking into this: If it's convenient, could you provide the output of the same command when booted into 3.6.x (and with a working controller)?
Still looking into this: If it's convenient, could you provide the output of the same command when booted into
3.6.x(and with a working controller)?
Do you mean with a working external controller connected?
No - I thought (apologies if I got this wrong) that when you booted back into 3.6.x the controller was working again.
Did it just break and stay broken?
No - I thought (apologies if I got this wrong) that when you booted back into
3.6.xthe controller was working again. Did it just break and stay broken?
No, it was fine when I rolled the update back.
Still looking into this: If it's convenient, could you provide the output of the same command when booted into
3.6.x(and with a working controller)?
Heres the output for that
If you open a terminal (desktop mode, ssh, whatever) and run:
/usr/share/jupiter_controller_fw_updater
you will repeat the process (with relevant stdio output) for the update.
If you post the results here I can identify the type of controller system you have on your Deck and also see if there is anything obviously wrong.
Depending on that data I can suggest a few other fixes. Push comes to shove, we can probably RMA your unit.
From the journal, looks like:
PTS: 65E4F1BA, STS: 65E4F1BA
[
{
"path": "/dev/hidraw3",
"vendor_id": 10462,
"product_id": 4613,
"serial_number": "",
"release_number": 512,
"manufacturer_string": "Valve Software",
"product_string": "Steam Deck Controller",
"usage_page": 65535,
"usage": 1,
"interface_number": 2,
"bus_type": 1,
"build_timestamp": 1709502906,
"secondary_build_timestamp": 1709502906,
"is_bootloader": false
}
]
Initial firmware update only necessary for galileo hardware
UPDATE: Type 1/2 Device is running builds 65E4F1BA | 65E4F1BA, updating to build (677C6202 | 677C6202 or 677C61FB)
2025-06-20 15:01:22,482 - __main__ - INFO - Looks like we are running an app. Resetting into bootloader
HWID: 31
Found candidate device, build timestamp 65E4F1BA, BL false, BL_Type 2, HYB false
Updating Homogeneous SECONDARY of Type 2 System
2025-06-20 15:01:33,665 - __main__ - INFO - Uploading /usr/share/jupiter_controller_fw_updater/D21_APP_REL_677C6202.bin to DogBootloader[Secondary], size: 241664
SUCCESS
Updating PRIMARY of Type 2 System
2025-06-20 15:01:58,712 - __main__ - INFO - Uploading /usr/share/jupiter_controller_fw_updater/D21_APP_REL_677C6202.bin to DogBootloader[Primary], size: 241664
SUCCESS
Firmware updated to 677C6202
But I should note that when the 3.6.x boot happened (after going back to the old image) it still had the original firmware, which is a little odd, based on my understanding of the firmware update.
If you open a terminal (desktop mode, ssh, whatever) and run:
/usr/share/jupiter_controller_fw_updateryou will repeat the process (with relevant stdio output) for the update.If you post the results here I can identify the type of controller system you have on your Deck and also see if there is anything obviously wrong.
Depending on that data I can suggest a few other fixes. Push comes to shove, we can probably RMA your unit.
So run that command you mentioned, then journalctl again?
If you open a terminal (desktop mode, ssh, whatever) and run:
/usr/share/jupiter_controller_fw_updateryou will repeat the process (with relevant stdio output) for the update.If you post the results here I can identify the type of controller system you have on your Deck and also see if there is anything obviously wrong.
Depending on that data I can suggest a few other fixes. Push comes to shove, we can probably RMA your unit.
Which file do I actually run? That command just spits out "is a directory".
Should be
sudo /usr/bin/jupiter-controller-update --check 2>&1 | tee firmware-update.log
Then attach firmware-update.log.
Or you can omit the --check to have it do the full update, but that probably doesn't matter here.
Should be
sudo /usr/bin/jupiter-controller-update --check 2>&1 | tee firmware-update.logThen attach
firmware-update.log.Or you can omit the
--checkto have it do the full update, but that probably doesn't matter here.
firmware-update.log Here we are.
Looked at this. You're def. on an older OS version that 3.7. Those Timestamps per your log: PTS: 65E4F1BA, STS: 65E4F1BA are from long ago.
Perhaps your reverted your OS update? If you update OS once again, the controller FW updates will kick off again on boot (via this same script). That output (from journalctl or through you running it expressly) should show us what's what. That's what we need to see.
Happy to look at it while it's trying to update to the new FW. Output should look similar to fledermaus comments above.
Looked at this. You're def. on an older OS version that 3.7. Those Timestamps per your log: PTS: 65E4F1BA, STS: 65E4F1BA are from long ago.
Perhaps your reverted your OS update? If you update OS once again, the controller FW updates will kick off again on boot (via this same script). That output (from journalctl or through you running it expressly) should show us what's what. That's what we need to see.
Happy to look at it while it's trying to update to the new FW. Output should look similar to fledermaus comments above.
Oh should I have run that command on the latest update, not 3.6.4?
Yeah. Is it that you have no left side controls currently? Or only after updating to the latest OS?
Yeah. Is it that you have no left side controls currently? Or only after updating to the latest OS?
Only after updating to current OS, though this issue started happening back on the 3.7.4 update on the stable channel, and every update since has had the same result. Going back to 3.6.4 fixes it.
Yeah. Is it that you have no left side controls currently? Or only after updating to the latest OS?
firmware-update-latest.log Heres the log on the latest Beta update.
OK, it shows that the left side is not programmed (probably true) or not communicating (also possible).
Please re-run w/o the --check option and let's see what happens.
OK, it shows that the left side is not programmed (probably true) or not communicating (also possible).
Please re-run w/o the --check option and let's see what happens.
controller-update.log Doesnt seem to have worked, even after a restart.
Still no input on Left side? It says it SUCCEEDED. ;)
Re-run w/ check again and if the timestamp here: "secondary_build_timestamp": 0 is still 0 then something is pretty messed up. What's your unit's serial #, BTW.
Still no input on Left side? It says it SUCCEEDED. ;)
Re-run w/ check again and if the timestamp here: "secondary_build_timestamp": 0 is still 0 then something is pretty messed up. What's your unit's serial #, BTW.
Serial Number is: FW1A336018A6
Seems liks its still the same
Still no input on Left side? It says it SUCCEEDED. ;)
Re-run w/ check again and if the timestamp here: "secondary_build_timestamp": 0 is still 0 then something is pretty messed up. What's your unit's serial #, BTW.
Ok quick update. For some reason, doing the check command broke ALL the controls, even when going back to gaming mode, but doing the non-check command brought back the right side controls. Left side is still broken though. In addition, running the check command after doing the non check update acts as if the update wasnt done at all, "secondary_build_timestamp" is still 0.
One thing to mention is that running the non check command has the Deck beep like it was woken from sleep, and the right side controls then start working again.
Yeah, the beep is the controller(s) booting. Check command is supposed to not leave the system in the bootloader, but w/ some other problems it's hard to say.
I think we've learned enough. My assessment is that there's something sad and broken w/ your Deck. I'm going to reach out to our CS and recommend an RMA. I would like to examine this unit as this issue isn't something we normally see.
Yeah, the beep is the controller(s) booting. Check command is supposed to not leave the system in the bootloader, but w/ some other problems it's hard to say.
I think we've learned enough. My assessment is that there's something sad and broken w/ your Deck. I'm going to reach out to our CS and recommend an RMA. I would like to examine this unit as this issue isn't something we normally see.
Just my luck to get an issue that hasnt been seen before lmao
Do I need to do anything more RN? If CS has the Serial Number of a Steam Deck, Im assuming they know the account it was sold to?
Someone should reach out. If not in the next few, hit this thread again and I'll follow up.
Someone should reach out. If not in the next few, hit this thread again and I'll follow up.
Will that be via Steam or Email?
SN would be helpful.
Serial Number is FW1A336018A6
My Steam Account is https://steamcommunity.com/profiles/76561198066221381/