Issue: ROG Ally sometimes captured before the controller is in full Gamepad mode

[pastaq]

The ROG Ally has a unique interface with multiple operating modes. The cold boot default mode is a dekstop mode with multiple shortcuts programmed into various combinations using the back paddles as the trigger under the same keycode for both. hid-Asus manages this device in Linux and during startup sets the device into gamepad mode, which ensures the back paddles are independent buttons, and that they don't cancel existing inputs. If the device is grabbed to early (presumably, this could be a driver issue) the hid-asus driver will fail to set the mode, the buttons will not be independent, and they will cancel any held input. As an example, if you were to set the back paddles to be the gear shift up/down in a game and the right trigger as your accelerator, during normal mode this would work as you would expect. Back paddles would permit both up and down shifting, and the accelerator input would not be affected by the buttons. In the controllers desktop mode however you would only have down shift available and the trigger would be canceled as if fully released and gameplay is interrupted. This is a problem even if you don't map the back paddles as they would still interrupt any held axis or button.

[pastaq]

Tagging @flukejones as he is the driver maintainer and may have some insight.

[flukejones]

I would suggest polling the sysfs item for mode change as internally the driver polls the device for change and setup completing

[pastaq]

[    4.086787] asus_wmi: ASUS WMI generic driver loaded
[    4.310820] asus 0003:0B05:1ABE.0001: Setting up ROG USB interface
[    4.310822] asus 0003:0B05:1ABE.0001: Setting up ROG Ally interface
[    4.315389] asus 0003:0B05:1ABE.0001: ROG Ally not ready, retry 0
[    4.321398] asus 0003:0B05:1ABE.0001: ROG Ally not ready, retry 1
[    4.327388] asus 0003:0B05:1ABE.0001: ROG Ally not ready, retry 2
[    4.327390] asus 0003:0B05:1ABE.0001: ROG Ally never responded with a ready

This repeats multiple times until it times out. We'll need to figure out a device specific quirk to poll for the mode change ans recommended.

[pastaq]

This only happens on a fresh boot. On restart or suspend/resume the device behaves as expected.

[flukejones]

It's a bit of a worry that is happening. Can you check if you can remap a key with the interface after fully booting? I'm wondering if the init sequence needs to be done earlier, or make the Ally driver parts wait until after hid_asus is loaded..

[pastaq]

I'm not sure what the syntax is for remapping via sysfs, but I was able to figure some stuff out.

Working from this directory:

[gamer@rogally 0003:0B05:1ABE.0001]$ pwd
/sys/bus/pci/devices/0000:00:08.1/0000:0a:00.3/usb1/1-3/1-3:1.0/0003:0B05:1ABE.0001

The gamepad_mode is set on the device when it boots, but the state is definitely wrong.

[gamer@rogally 0003:0B05:1ABE.0001]$ cat gamepad_mode 
1

Left and right (Asus Keyboard 3):

Event: time 1715298020.693947, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff3100a5
Event: time 1715298020.693947, type 1 (EV_KEY), code 185 (KEY_F15), value 1
Event: time 1715298020.693947, -------------- SYN_REPORT ------------
Event: time 1715298020.843944, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff3100a5
Event: time 1715298020.843944, type 1 (EV_KEY), code 185 (KEY_F15), value 0
Event: time 1715298020.843944, -------------- SYN_REPORT ------------
Event: time 1715298021.346959, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff3100a5
Event: time 1715298021.346959, type 1 (EV_KEY), code 185 (KEY_F15), value 1
Event: time 1715298021.346959, -------------- SYN_REPORT ------------
Event: time 1715298021.471967, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff3100a5
Event: time 1715298021.471967, type 1 (EV_KEY), code 185 (KEY_F15), value 0
Event: time 1715298021.471967, -------------- SYN_REPORT ------------

Setting the gamepad_mode does seem to resolve the issue:

[gamer@rogally 0003:0B05:1ABE.0001]$ echo 1 | sudo tee gamepad_mode 
1

Left and right (Asus Keyboard 1):

Event: time 1715298087.746207, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70069
Event: time 1715298087.746207, type 1 (EV_KEY), code 184 (KEY_F14), value 1
Event: time 1715298087.746207, -------------- SYN_REPORT ------------
Event: time 1715298087.882190, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70069
Event: time 1715298087.882190, type 1 (EV_KEY), code 184 (KEY_F14), value 0
Event: time 1715298087.882190, -------------- SYN_REPORT ------------
Event: time 1715298088.267226, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006a
Event: time 1715298088.267226, type 1 (EV_KEY), code 185 (KEY_F15), value 1
Event: time 1715298088.267226, -------------- SYN_REPORT ------------
Event: time 1715298088.404236, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006a
Event: time 1715298088.404236, type 1 (EV_KEY), code 185 (KEY_F15), value 0
Event: time 1715298088.404236, -------------- SYN_REPORT ------------

It also seems to happen when InputPlumber is not enabled or running at all, so EVIOGRAB isn't what is interfering on startup. We can force the gamepad_mode during startup as a workaround, but this would appear to be a driver issue.

[flukejones]

What version patch is being used?

[pastaq]

I'm not sure, the commit history isn't very clear. They are listed here: https://github.com/ChimeraOS/linux/commits/6.8/chimeraos/?before=e2ad833783cc88674135822c6bf4baeecf1e5ba5+35

@BoukeHaarsma23 might know more

[flukejones]

Alright looks like the last release of my work. I've a few ideas so I'll take a potshot at it.

[github-actions[bot]]

:tada: This issue has been resolved in version 0.32.3 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: