Rog Ally back paddles mapping #1088
Comments
|
@Cheng77777 hello, they produce same key code, so most probably - no :) |
|
Courious how AC implement separate key mappings |
|
@Cheng77777 i have a feeling it binds it somehow on hardware level, i.e. pedals just start physically emitting a new key codes. It’s probably some usb command that tells controller to do so. But since i have returned my Ally back to store i can’t really investigate that :) |
|
well, it makes sense to me, wanted to test the key code myself but I did not find the propper tool lol. |
|
@Cheng77777 You can download https://www.hhdsoftware.com/device-monitoring-studio and then intercept all USB traffic between your controller (it's a USB device) and armoury for example Most probably the moment you set a specific binding in AC it would send some payload to the device telling to do that |
|
Do you guys have an Ally to test this with? There's been some research on the linux side for the keycode mapping and it appears like there's a hardware default for the back keys to be a sticky keys switch on single button press and release on pressing both of them. From what I can tell there's three modes switched between in AC with the most ideal one being M1 and M2 split into their own functions. It would be great if you had an option to set up the keybindings with a default of Armory Crate key mapped to Guide, Control Center function set to CTRL2 and the back buttons set to standard keysyms that are unbound. Mostly I think it would be great for someone with proper tools to capture the configuration method out of AC to put the controller into a coherent mode since nobody seems to be able to figure it out; and you guys seem to have the most experience with ASUSs braindead hardware configuration methods. |
|
Here's the init to map the back panels to a real event of ctrl F9 and ctrl F10. Also attached is the pcap and some notes. I hope this gets us a good init in your wonderful software. |
|
@ggrensteiner hello, thanks. I have returned my Ally back to store, so can't really debug / test it unfortunately :) I was trying to understand your payloads
I think it would be cool to capture more data (i.e. set different bidings, probably simple one-keys as well and try to decypher meaning of each byte) |
|
And a config package to go to mouse mode, and other to go back to poweron default |
|
This is a config payload that loads a bunch of memory space on the N-Key device that's pretending to be a keyboard, mouse and xbox controller. It changes the keysyms coming out of the device completely. I can do a compare of what they were before to what they become next weekend if you like. |
|
Did you guys make any progresses here? I have too much on my plate already to focus on the Ally alone. |
|
@Valkirie nope, I don't have Ally at the moment :) so it's effectively unrealistic to debug that USB-protocol that sets bindings |
I do have an ally since a few days.... May I help with the USB debugging? What do you need? |
|
@IceStormNG pretty much the same you did for mouse protocol. Set backpedal buttons to emit certain keys in AC, and intercept USB packet with command Apparently those buttons can be programmed to emit (any?)key on hardware level via special usb payload |
|
I will have a look at later. |
|
Ok. It looks like I found the packet. Only problem is: I cannot make any rhyme out of the codes they send for the key setting. It is not the HID keycode. This sets both Macro keys to F11. HID keycode for F11 is 0x44 This sets M1 to A and M2 to B (keyboard). HID Keycodes for A is 0x04 and for B 0x05. This sets M1 to C and M2 to B (keyboard). HID Keycodes for C is 0x05 and for B 0x05. It looks like the second marked byte is M1 and the first is M2 This sets M1 to 'Take screenshot' and M2 to B (keyboard). Looks like "2" is for "Keyboard key" and 5 for "Action". It also looks like the keycode is 2 bytes. This sets M1 to 'Take screenshot' and M2 to X (Controller). Hm.. maybe it's 3 bytes for the keycode? Or the first is for "Controller" ,second for "Keyboard" and 3rd for "Special stuff" This sets M1 to 'Left Mouse' and M2 to X (Controller). Make it 4 byte while we're at it. 4th byte seems for mouse actions. WTF ASUS This sets M1 to 'Left Mouse' and M2 to 'CTRL + ALT + ESC' . Urm..... For real? Alright we can use up to 5 keys in macros This sets M1 to 'Left Mouse' and M2 to 'A S U C K' . (lmao) That's enough ASUS BS for today. |
|
@IceStormNG actually this is already good! Main problem here was that both backpedals produced same keycode, as far they produce different ones - that would be enough for G-Helper to listen (i.e. register global hotkeys) and process them accordingly This is very similar to how M1/M2 buttons work on laptop (they emit hardware volume up / down keys). I assume you can also make them emit something else on hardware level (via AC), but in app - i just listen to volume keys directly |
|
So, you plan to set them to something specific, then just use GHelper to handle the hotkeys instead of making a tool to configure them on hardware level? These are the USB Payloads to set the M1/M2 keys. They do emit the correct keycode (not the one that we sent, but the equivalent one) on the HID Keyboard device. |
|
They produce the same keycodes by default, because, out-of-the-box, they're both configured to "Secondary Function" and. So you would have to set them to something different before, then they also become different. I'm not sure though, whether the Ally saves the keycodes in hardware permanently or whether they have to be re-set after a powercycle. |
|
@IceStormNG well, sounds like it will be easier (or at least understandable). Just bind M2 to something non-default (like emit F23), and then process F23 as hotkey. Only trouble here - that i don't know how to emit non-keyboard actions (like gamepad X or start, or so), but this applies to all bindings not only backpedals :) Alternative - is to literally build a table of codes for each key ... :| |
|
We could build a table for the controller and mouse keys, and do the keyboard stuff in software. The Controller keys are limited. But I'm not going to test out all 102+ Keyboard keys with AC and a USB packet logger because ASUS just couldn't use the HID codes. |
Yeah.. that will not work. AC won't let you pick such a key. So I cannot tell you what code we would have to send to do that. |
|
@IceStormNG yeah, i would say just separate M2 to something else first :) that will be already a big step. I wonder if it's possible to set it to emit a HID keycode as it does by default ,but different one (not 165) |
|
@IceStormNG btw, i'm sure that even on laptops Asus uses same approach for binding M-keys (i.e. they start emitting something else on hardware level). I just didn't bother decoding it in a first place, as just listening to original keycodes and processing them is way easier. |
|
For keyboard, we have those as options. And I don't think we should abuse any of those. |
|
@IceStormNG there are a lot of exotic keys in windows that can be used |
|
Yes, but we do not know the ASUS keycodes for that. |
|
To Program the M2 key to such a key, you need to send the keycode, but ASUS does not use the HID keycodes to configure the device. They use a different code to send over to the Ally, then emit the "correct" code via the HID keyboard. Idk whether there is any correlation between the HID codes and the ASUS codes or whether ASUS just made their own table. |
|
@IceStormNG i know, but i mean that it's possible to pick something even more exotic than F23 Key-combo can also work |
|
Otherwise, we would just need a table to map ASUS -> HID and we could just programm the damn thing in hardware. |
|
Though here comes another issue. ASUS uses a non HID transfer function to send the data to the Ally. So... we would also kinda need some way to send the data in the same way. |
|
Alright. I really did it and fully decoded the back pedal mapping protocol with all keys that AC supports. Endpoint is the ASUS Device VID: 0xB05 PID: 0x1ABE, Interface Index 2 |
|
@IceStormNG great! Amazing job and a very impressive research. Looking at the codes - seems like Asus used completely custom protocol for that! So the only thing missing is how to mark usb-packet as Class Specific Request ? I will try to check what AC sends to asus keyboards on laptops for macro keys, and will try to replicate at least that part ... |
Very well documented work indeed. Eager to see if you guys succeed here. |
|
@IceStormNG @seerge , from the packages that @ggrensteiner shared with the Handheld Companion team here: Valkirie/HandheldCompanion#671 (comment) I was able to determine that this package should set the back buttons to work as F17 and F18?
I have an ROG Ally, but I am very unfamiliar with HID packages, is there some tool or C# library I could (ab)use to send this to the correct HID device to see what happens? |
|
Just a small update from my side, I have (within the HC application) a working prototype where I send the all the HID commands. I'm not there yet though. If I first set the gamepad to default with backpaddles to something like F1 and F2 using Armoury Crate, then close all of that and run my commands from HC, the gamepad is default and both back paddles return F17. The command I'm sending was confirmed to work to make them F17 and F18 under ChimeraOS so I must be doing something wrong. I'll be double checking and comparing the full command I'm sending and perhaps try some timeouts or something. Will continue shortly. |
|
@ggrensteiner @Cheng77777 I have released a first preview of custom bindings for a whole controller https://github.com/seerge/g-helper/releases/tag/v0.148 This also covers M1/M2 buttons obviously :) Thanks for the research to @IceStormNG |
|
P.S. It's still not polished visually as I have some better ideas for UI Bindings work only when you select Gamepad controller more (or if you have it on Auto and it is gamepad stage, i.e. in game) |
|
Closing as completed now :) |
Can the back paddles of ROG Ally be somehow separately mapped like in AC?
The text was updated successfully, but these errors were encountered: