-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue: ROG Ally sometimes captured before the controller is in full Gamepad mode #76
Comments
Tagging @flukejones as he is the driver maintainer and may have some insight. |
I would suggest polling the sysfs item for mode change as internally the driver polls the device for change and setup completing |
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. |
This only happens on a fresh boot. On restart or suspend/resume the device behaves as expected. |
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.. |
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:
The gamepad_mode is set on the device when it boots, but the state is definitely wrong.
Left and right (Asus Keyboard 3):
Setting the gamepad_mode does seem to resolve the issue:
Left and right (Asus Keyboard 1):
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. |
What version patch is being used? |
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 |
Alright looks like the last release of my work. I've a few ideas so I'll take a potshot at it. |
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.
The text was updated successfully, but these errors were encountered: