Rog Ally - Steam button and triple dot button sometimes don't work after sleeping while in game
Closed this issue · 17 comments
Your system information
- Steam client version: 1757117424 (Beta)
- SteamOS version: 3.8 (Main)
- Opted into Steam client beta?: Yes
- Opted into SteamOS beta?: Main
- Have you checked for updates in Settings > System?: Yes
Please describe your issue in as much detail as possible:
In general, everything is working great on my Rog Ally on the Main OS branch and stable Steam client. I switched to the Beta client because of a couple of minor quirks with control in the store interface, but the issue in the title occurs regardless of steam client branch.
If I start a game, the 2 "overlay" buttons work as expected to bring up their respective menus, which pop in over the running game.
When in game, press the power button to sleep the device and it sleeps, press again and it wakes - all of that is working beautifully.
The problem is that some times the Steam button and the quick menu button (...) are unresponsive, after waking from sleep while in-game. I am unsure how predictable this is, but it happens more often than not.
I should note that I also have a Steamdeck running on Stable OS and client, and of course I've never experienced this issue, with the specific game I've mentioned here or any other.
Steps for reproducing this issue:
- Install and configure Rog Ally with SteamOS Main
- Launch a game (Castlevania Lords of Shadow in my testing)
- Press Steam or Quick menu button
Does it still happen if you change the Steam client channel from Beta to Stable? You can leave the System Update channel on SteamOS Main.
Does it still happen if you change the Steam client channel from Beta to Stable? You can leave the System Update channel on SteamOS Main.
I've just checked this and yes, it happens on the both stable and beta client versions.
I've only had the device on SteamOS for about a week now, but as I scrutinize this issue more closely I'm getting more detail on the behavior. I've just restarted the device and I've noticed those 2 buttons are not working after a restart.
I've also noticed that the wifi doesn't always automatically reconnect after sleep. I know that's a different device subsystem but it feels like it could be related to sleep/wake power management.
I've run a couple of sleep/wake tests, and interestingly, the button functionality came back on the second cycle. This is following the restart (from the SteamOS power menu) where the buttons did not respond. I think that rules out any kind of UEFI device driver interaction.
Another point after further testing - when the problem occurs, it's not limited to in game, they don't work on the SteamOS gui either.
This feels like maybe a udev race condition... I've set up ssh access on this device already - what could I look for when it's in the problem state? Is there a usb or i2c device, or a kernel module that I can take a look at to try to resolve this?
I am no stranger to Linux, so I think I can offer some worthwhile data on this problem.
Does it happen with every game or only certain games? So far I have not been able to reproduce the issue yet with my own ROG Ally on SteamOS 3.8, but I don't own Castlevania Lords of Shadow so I've been using Ori and the Will of the Wisps.
Next time it happens, can you grab a SteamOS system report? Settings -> System -> Advanced -> System Report -> Create Report. This will include logs both from your current boot and your previous boot, so even if you have to reboot the system report should still capture the relevant logs. Should hopefully give more details about where things are going awry.
Wi-Fi connectivity is unrelated, I have the same issue on multiple different SteamOS devices without controller issues.
Does it happen with every game or only certain games? So far I have not been able to reproduce the issue yet with my own ROG Ally on SteamOS 3.8, but I don't own Castlevania Lords of Shadow so I've been using Ori and the Will of the Wisps.
I've just tested after a full shutdown and startup. I confirmed the quick menu button worked, launched Silk Song, left it at the menu, and pressed the power button to sleep the device. I woke the device and the 2 buttons are non-responsive. So it doesn't appear to be game specific.
Next time it happens, can you grab a SteamOS system report?
Settings -> System -> Advanced -> System Report -> Create Report. This will include logs both from your current boot and your previous boot, so even if you have to reboot the system report should still capture the relevant logs. Should hopefully give more details about where things are going awry.
I generated a report and I'm looking through it. Didn't want to post it here as it's huge and I don't know if it contains any sensitive data.
Wi-Fi connectivity is unrelated, I have the same issue on multiple different SteamOS devices without controller issues.
Noted, and thanks!
hmm, so far i still cannot reproduce the issue in Silksong on SteamOS Main with the Stable client after ~30 suspend/resume cycles of varying lengths of time and plugged/unplugged :(
have you used anything that makes third party modifications to the system like plugins? those would be the first things i would try eliminating as a factor if so.
hmm, so far i still cannot reproduce the issue in Silksong on SteamOS Main with the Stable client after ~30 suspend/resume cycles of varying lengths of time and plugged/unplugged :(
have you used anything that makes third party modifications to the system like plugins? those would be the first things i would try eliminating as a factor if so.
Ah, I should have mentioned that, though the problem existed before I made any such modifications. I installed decky loader and huesync, just to be able to stop the rainbow front panel LEDS as they are quite obnoxious. I uninstalled decky loader before filing this bug report, and since the problem existed prior to installing any third party software, it really can't be a factor.
I'm used to scanning logs and debugging kernel drivers as my day job has me working on exactly those things. I searched the system report for anything I could find related to input events, udev, or anything else that might be related. So far this is the only thing that looked like it could be related:
Sep 08 14:36:53 rog-ally gamescope-session[3020]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 08 14:36:53 rog-ally gamescope-session[3020]: > Warning: Unsupported maximum keycode 708, clipping.
Sep 08 14:36:53 rog-ally gamescope-session[3020]: > X11 cannot support keycodes above 255.
Sep 08 14:36:53 rog-ally gamescope-session[3021]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Sep 08 14:36:53 rog-ally gamescope-session[3021]: > Warning: Unsupported maximum keycode 708, clipping.
Sep 08 14:36:53 rog-ally gamescope-session[3021]: > X11 cannot support keycodes above 255.
Sep 08 14:36:53 rog-ally gamescope-session[3020]: > Warning: Could not resolve keysym XF86RefreshRateToggle
Sep 08 14:36:53 rog-ally gamescope-session[3021]: >
Sep 08 14:36:53 rog-ally gamescope-session[3020]: >
Sep 08 14:36:53 rog-ally gamescope-session[3021]: Warning:
Sep 08 14:36:53 rog-ally gamescope-session[3020]: Warning: Could not resolve keysym XF86Accessibility
Sep 08 14:36:53 rog-ally gamescope-session[3021]: Could not resolve keysym XF86RefreshRateToggle
Sep 08 14:36:53 rog-ally gamescope-session[3020]: > Warning: Could not resolve keysym XF86DoNotDisturb
Sep 08 14:36:53 rog-ally gamescope-session[3021]: > Warning: Could not resolve keysym XF86Accessibility
Sep 08 14:36:53 rog-ally gamescope-session[3021]: > Warning: Could not resolve keysym XF86DoNotDisturb
Sep 08 14:36:53 rog-ally gamescope-session[3020]: Errors from xkbcomp are not fatal to the X server
Sep 08 14:36:53 rog-ally gamescope-session[3021]: Errors from xkbcomp are not fatal to the X server
Are those 2 buttons mappable as any standard XCB symbols? it would be nice if I knew more about what I'm looking for in here...
those logs can be ignored, even Steam Decks generate those from gamescope at various points.
I would look for logs mention hid in some capacity but if there really is nothing suspicious, the other idea that comes to mind is making sure you're on both the latest BIOS update (which can be installed via EZFlash in the BIOS or on Windows) AND making sure you're on the latest MCU firmware version (afaik this has to be done on Windows). A windows-to-go USB drive via Rufus is what I use for firmware updates on my handhelds.
Specifically the MCU firmware is important because the original ROG Ally had suspend issues that should be resolved by Asus in MCU fw. version 319.
OK, I've got something useful. In a fully working state, we have these raw hid devices enumerated:
ls -lhrt /dev/hidraw*
crw-rw----+ 1 root root 245, 3 Sep 8 21:09 /dev/hidraw3
crw-rw----+ 1 root root 245, 1 Sep 8 21:09 /dev/hidraw1
crw-rw----+ 1 root root 245, 0 Sep 8 21:09 /dev/hidraw0
c--------- 1 root root 245, 2 Sep 8 21:09 /dev/hidraw2
crw-rw----+ 1 root root 245, 4 Sep 8 21:09 /dev/hidraw4
In the problem state, it looks like this:
$ ls -lhrt /dev/hidraw*
crw-rw----+ 1 root root 245, 3 Sep 8 17:58 /dev/hidraw3
crw-rw----+ 1 root root 245, 4 Sep 8 17:58 /dev/hidraw4
AFAIK there is no guarantee as to which device is which, it's down to which happens to be enumerated first on that boot, so I'll have to check how they are enumerated in a good state, then get it into the bad state and check which are missing.
On a fresh power cycle with everything working, here's what I've got:
$ journalctl -b | grep hidraw
Sep 08 21:09:11 rog-ally kernel: hid-generic 0003:0B05:1ABE.0001: input,hidraw0: USB HID v1.10 Keyboard [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:09:00.3-3/input0
Sep 08 21:09:11 rog-ally kernel: hid-generic 0003:0B05:1ABE.0002: input,hidraw1: USB HID v1.10 Mouse [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:09:00.3-3/input1
Sep 08 21:09:11 rog-ally kernel: hid-generic 0003:0B05:1ABE.0003: input,hiddev96,hidraw2: USB HID v1.10 Device [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:09:00.3-3/input2
Sep 08 21:09:12 rog-ally kernel: hid-generic 0018:0603:F200.0004: input,hidraw3: I2C HID v1.00 Device [NVTK0603:00 0603:F200] on i2c-NVTK0603:00
Sep 08 21:09:12 rog-ally kernel: asus 0003:0B05:1ABE.0001: input,hidraw0: USB HID v1.10 Keyboard [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:09:00.3-3/input0
Sep 08 21:09:12 rog-ally kernel: asus 0003:0B05:1ABE.0002: input,hidraw1: USB HID v1.10 Mouse [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:09:00.3-3/input1
Sep 08 21:09:13 rog-ally kernel: hid-multitouch 0018:0603:F200.0004: input,hidraw3: I2C HID v1.00 Device [NVTK0603:00 0603:F200] on i2c-NVTK0603:00
Sep 08 21:09:13 rog-ally kernel: asus_rog_ally 0003:0B05:1ABE.0003: hidraw2: USB HID v1.10 Device [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:09:00.3-3/input2
Sep 08 21:09:14 rog-ally inputplumber[1225]: [2025-09-09T01:09:14Z INFO inputplumber::input::manager] Started hidraw device discovery thread
Sep 08 21:09:14 rog-ally inputplumber[1225]: [2025-09-09T01:09:14Z INFO inputplumber::input::manager] Found a matching hidraw device hidraw://hidraw2 in config "/usr/share/inputplumber/devices/50-rog_ally.yaml", creating CompositeDevice
Sep 08 21:09:14 rog-ally inputplumber[1225]: [2025-09-09T01:09:14Z INFO inputplumber::input::source::hidraw] Detected ROG Ally
Sep 08 21:09:15 rog-ally kernel: hid-generic 0003:28DE:12FD.0005: hidraw4: USB HID v10.00 Device [ROG Ally Controller] on
For this boot, enumeration of hid devices look like:
/dev/hidraw0 -
/dev/hidraw1 -
/dev/hidraw2 - CompositeDevice defined in "/usr/share/inputplumber/devices/50-rog_ally.yaml"
/dev/hidraw3 - i2c touchscreen input
/dev/hidraw4 - "ROG Ally Controller" (gamepad-related buttons, analog sticks?)
I suspect that /dev/hidraw0 and /dev/hidraw1 represent the 2 buttons that go missing. I'm going to dig deeper and look at their suspend states.
Specifically the MCU firmware is important because the original ROG Ally had suspend issues that should be resolved by Asus in MCU fw. version 319.
I already updated the UEFI to the latest a few days ago (342), but this is the first I've read about the MCU firmware. Searching for the USB OID of the devices that are disappearing led me to some kernel patch notes from CachyOS which points to those devices being tied to the MCU...
This is a used device that I got second hand, and I have no idea of the age, so it very well could be the MCU firmware... I'll look into it and follow up.
https://rog.asus.com/gaming-handhelds/rog-ally/rog-ally-2023/helpdesk_download/ It’s a little hard to find but the MCU fw updates are listed under Drivers & Tools -> Hotfix -> Show All. There should be a kernel dmesg warning that tells you if it’s out of date, but I’m pretty sure that warning is always returning 0 at the moment with the current Ally patch set and I haven’t really had the time to look into it yet.
https://rog.asus.com/gaming-handhelds/rog-ally/rog-ally-2023/helpdesk_download/ It’s a little hard to find but the MCU fw updates are listed under Drivers & Tools -> Hotfix -> Show All. There should be a kernel dmesg warning that tells you if it’s out of date, but I’m pretty sure that warning is always returning 0 at the moment with the current Ally patch set and I haven’t really had the time to look into it yet.
Nothing in dmesg, however I've confirmed it's on an older MCU firmware with fwupdmgr:
$ sudo fwupdmgr get-devices
...
├─ASUSTeK Computer Inc. N-KEY Device:
│ │ Device ID: <redacted>
│ │ Vendor: HIDRAW:0x0B05
│ │ GUID: <redacted> ← HIDRAW\VEN_0B05&DEV_1ABE
│ │ Device Flags: • Internal device
│ │ • Can tag for emulation
│ │
│ ├─Microcontroller 0:
│ │ Device ID: <redacted>
│ │ Current version: 317
│ │ Vendor: HIDRAW:0x0B05
│ │ GUID: <redacted>← HIDRAW\VEN_0B05&DEV_1ABE&PART_RC71LS
│ │ Device Flags: • Internal device
│ │ • Unsigned Payload
│ │
│ └─Microcontroller 1:
│ Device ID: <redacted>
│ Current version: 317
│ Vendor: HIDRAW:0x0B05
│ GUID: <redacted> ← HIDRAW\VEN_0B05&DEV_1ABE&PART_RC71LM
│ Device Flags: • Internal device
│ • Unsigned Payload
...
...so this is almost certainly being caused by outdated MCU firmware.
I am sorry to have taken your time on this, though I appreciate it quite a lot!
I'll get the MCU firmware updated, confirm the issue is fixed and then close this issue with a summary for anyone else who comes across it.
No worries. it’s a scenario that’s ideally addressed in a way that’s not “boot into windows to do this update” but that’s the current situation for updating this type of firmware
No worries. it’s a scenario that’s ideally addressed in a way that’s not “boot into windows to do this update” but that’s the current situation for updating this type of firmware
It would be great if we could use the lvfs and fwud to handle these kinds of firmware updates. Makes me really appreciate vendors like Dell, Lenovo and 8BitDo that seem to be actively supporting an open distribution mechanism.
Closing this issue, as I've updated the MCU firmware to 319, tested over several sleep/wake cycles, and the problem is now fully resolved!
Thank you kindly, @matte-schwartz for your assistance!
For posterity, I used Ventoy and Hiren's BootCD PE as I already have a Ventoy stick kicking around, and using the wimboot option at boot time, this worked great.
Great. I'll look at figuring out how the version check broke so its a bit easier to spot this issue in the future.
I'm getting the same problem here, in short, how can I update the firmware?
I'm getting the same problem here, in short, how can I update the firmware?
You can get the MCU firmware from Asus here by selecting Windows 11 in the OS drop-down, and scrolling down the page to the "Hotfix" section.
On a stock Ally you would just download and install this on the device itself as it would be running Windows. If, like me, you've already installed SteamOS and want to keep it that way, then you will need to boot into a Windows "live" environment of some kind.
@matte-schwartz referenced using Windows to Go and Rufus above, however in my case:
... I used Ventoy and Hiren's BootCD PE as I already have a Ventoy stick kicking around, and using the
wimbootoption at boot time, this worked great.
Essentially, you need to boot your Ally to a Windows system temporarily, just long enough to run the hotfix that you'd get from the Asus download page. This upgrades the MCU and then you can shutdown or reboot.
You can verify that the MCU firmware is updated in UEFI/BIOS or by running sudo fwupdmgr get-devices and looking for the newer version to be reflected there., as referenced above.