Wireshark capture data for GX502

[flukejones]

Here is the capture data from wireshark for this model laptop. I wish I had extra time to help with this, but I think someone who already knows how most of this works would be in a better position to do the work than me. Most of it seems to be I/O from 2.4.*, eg usb.dst matches "2.4."

gx502-other-kb-functions.zip
gx502-rgb-wireshark.zip

[flukejones]

Using a print statement to print the USB cfg in the python prototype I get this:

  CONFIGURATION 1: 100 mA ==================================
   bLength              :    0x9 (9 bytes)
   bDescriptorType      :    0x2 Configuration
   wTotalLength         :   0x5b (91 bytes)
   bNumInterfaces       :    0x3
   bConfigurationValue  :    0x1
   iConfiguration       :    0x0 
   bmAttributes         :   0xe0 Self Powered, Remote Wakeup
   bMaxPower            :   0x32 (100 mA)
    INTERFACE 0: Human Interface Device ====================
     bLength            :    0x9 (9 bytes)
     bDescriptorType    :    0x4 Interface
     bInterfaceNumber   :    0x0
     bAlternateSetting  :    0x0
     bNumEndpoints      :    0x1
     bInterfaceClass    :    0x3 Human Interface Device
     bInterfaceSubClass :    0x1
     bInterfaceProtocol :    0x1
     iInterface         :    0x3 Error Accessing String
      ENDPOINT 0x81: Interrupt IN ==========================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :   0x81 IN
       bmAttributes     :    0x3 Interrupt
       wMaxPacketSize   :   0x40 (64 bytes)
       bInterval        :    0x1
    INTERFACE 1: Human Interface Device ====================
     bLength            :    0x9 (9 bytes)
     bDescriptorType    :    0x4 Interface
     bInterfaceNumber   :    0x1
     bAlternateSetting  :    0x0
     bNumEndpoints      :    0x1
     bInterfaceClass    :    0x3 Human Interface Device
     bInterfaceSubClass :    0x1
     bInterfaceProtocol :    0x1
     iInterface         :    0x1 ASUSTeK Computer Inc.
      ENDPOINT 0x82: Interrupt IN ==========================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :   0x82 IN
       bmAttributes     :    0x3 Interrupt
       wMaxPacketSize   :   0x40 (64 bytes)
       bInterval        :    0x1
    INTERFACE 2: Human Interface Device ====================
     bLength            :    0x9 (9 bytes)
     bDescriptorType    :    0x4 Interface
     bInterfaceNumber   :    0x2
     bAlternateSetting  :    0x0
     bNumEndpoints      :    0x2
     bInterfaceClass    :    0x3 Human Interface Device
     bInterfaceSubClass :    0x1
     bInterfaceProtocol :    0x1
     iInterface         :    0x1 ASUSTeK Computer Inc.
      ENDPOINT 0x83: Interrupt IN ==========================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :   0x83 IN
       bmAttributes     :    0x3 Interrupt
       wMaxPacketSize   :   0x40 (64 bytes)
       bInterval        :    0x1
      ENDPOINT 0x4: Interrupt OUT ==========================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :    0x4 OUT
       bmAttributes     :    0x3 Interrupt
       wMaxPacketSize   :   0x40 (64 bytes)
       bInterval        :    0x1

[flukejones]

Extra data. As it turns out rogauracore works fine with this laptop (except for multi modes). I did reinstall Pop!_OS, but unsure what changed. Kernel is Linux pop-os 5.3.0-7625-generic #27~1576337002~19.10~bc3488b-Ubuntu SMP Sat Dec 14 18:31:03 UTC x86_64 x86_64 x86_64 GNU/Linux.

gx502-rgb-selecting.zip

[flukejones]

Did a cold reboot and now it doesn't work. Unsure what changed. On the flipside the keyboard now retains the last used setting...

I'm going to reboot to Windows, change a setting, then reboot to Linux and try again. Might be an initialization thing as the sudden working in Linux was after I cycled through settings with wireshark. Not really sure how to capture the startup sequence - I'll try uninstall AmoryCrate and reinstall with wireshark going.

[flukejones]

I can confirm that Windows does initialise the LED controller, and after booting to Windows and opening ArmouryCrate it allows rogauracore to work in Linux.

I disabled as much as possible on the USB bus the LED controller seems to be on, then opened Armoury (simply opening it did nothing), then switched to the Aura tab which then caused some traffic.

gx502-rgb-open-aura-tab.zip

Output from rogauracore is the same in both working and non-working:

parse speed 2
args:
color1 48 231 9
color2 98 218 127
color3 0 0 192
color4 234 9 98
brightness 2
single_static
constructed 1 messages:
message 0: 5a ba c5 c4 02 00 00 00 00 00 00 00 00 00 00 00 00 
Initialising libusb
Initialised libusb.
Found 7 USB devices.
Checking device 1d6b:0003, address 1
Checking device 046d:c52b, address 2
Checking device 8087:0aaa, address 4
Checking device 0b05:1866, address 3
Found ROG Aura Core keyboard.
Opened USB device.
Auto detach kernel mode set.
Got configuration descriptor.
Found 3 interfaces on the USB device.
Claimed interface 0.
Successfully sent all messages.

[JoshDreamland]

Apologies; only just saw this thread. Thanks for the dumps! Your symptoms are weird. Let me clarify two things...

1. When rogauracore works, everything works except the multi-color options. You can set the brightness and change the color to any single color you like.
2. When it doesn't work, nothing works at all. Whatever mode Windows last set is there to stay, and rogauracore is just ineffective for no reported reason.

If those statements are accurate, then it sounds as though there's some wake-up message we're missing.

Unfortunately, if we are missing a wake-up message, you haven't captured it. The messages sent when you switch to the Aura tab are just SINGLE_STATIC(RED), SET().

If it's helpful, these are some messages that play on my machine when ArmouryCrate is first installed:

uint8_t MESSAGE_UNKNOWN[MESSAGE_LENGTH] = {0x5d, 0xbf};
uint8_t MESSAGE_UNKNOWN2[MESSAGE_LENGTH] = "\x5d" "ASUS Tech.Inc.";
uint8_t MESSAGE_UNKNOWN3[MESSAGE_LENGTH] = "\x5d\x05\x20\x31\x00\x08";
uint8_t MESSAGE_UNKNOWN4[MESSAGE_LENGTH] = "\x5e" "ASUS Tech.Inc.";
uint8_t MESSAGE_UNKNOWN5[MESSAGE_LENGTH] = "\x5e\x05\x20\x31\x00\x08";

If you're desperate, you can give those a shot. I like to just play them manually where Will is playing the SET/APPLY messages.

Another theory is that asus-wmi is saying something stupid when it starts up. If I send garbage to my keyboard, it will start ignoring me, too. However, on my machine, this renders the keyboard completely inoperable. That said, other users have reported that various facets of their machines will become unresponsive when using rogauracore. In fact, on Will's machine, his aura brightness keys become inoperable after issuing any commands from rogauracore. Perhaps the opposite is true on your machine, and asus-wmi sets your keyboard in some BIOS compatibility mode. Even then, you may be able to reset your keyboard using the correct messages.

Here's what I can see from your Wireshark dumps:

1. Your single_static is capped by 0xe1. Under Will's single_static routine, add m[7] = 0xe1 and see if that does anything for you.
2. Your startup routine only calls SET after changing the color. It does not call APPLY. I doubt this is the culprit, but it's another tweak to try.
3. Your brightness is controlled "normally." Unlike on my keyboard, but like Will's, your brightness functions don't use a specially-formatted data block. I would expect asus-wmi to be able to handle your brightness (though, as I said, this may actually be the cause of your other issues). Do your normal aura brightness keys work without this tool?
4. Your firmware is radically different than Will's machine or mine. Will sets rainbow mode by telling his keyboard to alternate Red, Yellow, Cyan, and Magenta. I set rainbow mode by telling my keyboard "rainbow mode." Your machine? ArmouryCrate is updating every single key cyclically, sending literally hundreds of messages per second. It is controlling the animation on a per-key basis, sending messages that appear to control keys in 11 addressable regions, 16 keys at a time. I can't tell what keys these regions map to, although I could actually get a good idea based on the grading I'm seeing, here, if I sat down and looked at it. There's apparently some overlap between regions, unless your keyboard happens to have 170ish keys.

Sorry, that's a lot of information. If you have some free time, please read over that a couple of times, and you'll see there's a lot you can try. If none of that works, my recommended next step is to boot Windows, uninstall ArmouryCrate, reboot, start the ArmouryCrate install process, and then start Wireshark right before pressing "install." When the keyboard lights up, that payload will likely have anything we're missing to reset your keyboard in it.

[JoshDreamland]

Actually, perhaps this is entirely a function of whether asus-wmi is installed. Is it listed under lsmod? It might even be some kind of data race based on when the module is initialized. That is, perhaps your keyboard will work if you disable asus-wmi, or load it only after boot has completed.

[flukejones]

Very sorry about slow response. Been extremely busy with work.

4. Rainbow mode through auracore works fine, I was a bit surprised by the constant stream for sure, but it doesn't need this for rainbow mode to work.
5. Brightness keys are non-responsive due to all the functions keys being on a different controller from what I can see. Linux seems to pick that up as some sort of analogue(!) controller (issue here), actual wireshark data is quite different.

I haven't had a chance to try your other suggestions. But I do know asus_wmi has no effect.

I did uninstall then reinstall Crate. There appeared to be another driver somewhere enabling control, but I think this only enabled the secondary keys controller so that the aura effects cycled through the stock firmware ones.

Hell, this sort of rubbish pisses me off a bit when it comes to Linux and gaming laptops. Damned good laptop, but boy howdy don't you dare use another OS 🙄

[flukejones]

gx502-install-crate.zip

[flukejones]

Finally had more time to pursue this. It looks like for the GX502GW:

Your startup routine only calls SET after changing the color. It does not call APPLY. I doubt this is the culprit, but it's another tweak to try.

Is the solve here. Somehow I missed this before.

Putting the machine to sleep then waking resets all but the brightness.

Edit: grumble turns out I must have booted windows first.

[flukejones]

Looks like this actually works, just after claiming the interface I put:

    // TRY TO INIT
    nRetval = controlTransfer(pHandle, MESSAGE_UNKNOWN, MESSAGE_LENGTH);
    if (nRetval < 0) goto release;
    nRetval = controlTransfer(pHandle, MESSAGE_UNKNOWN2, MESSAGE_LENGTH);
    if (nRetval < 0) goto release;
    nRetval = controlTransfer(pHandle, MESSAGE_UNKNOWN3, MESSAGE_LENGTH);
    if (nRetval < 0) goto release;
    nRetval = controlTransfer(pHandle, MESSAGE_UNKNOWN4, MESSAGE_LENGTH);
    if (nRetval < 0) goto release;
    nRetval = controlTransfer(pHandle, MESSAGE_UNKNOWN5, MESSAGE_LENGTH);
    if (nRetval < 0) goto release;
    V(printf("Sent INIT messages.\n"));

To send the:

uint8_t MESSAGE_UNKNOWN[MESSAGE_LENGTH] = {0x5d, 0xbf};
uint8_t MESSAGE_UNKNOWN2[MESSAGE_LENGTH] = "\x5d" "ASUS Tech.Inc.";
uint8_t MESSAGE_UNKNOWN3[MESSAGE_LENGTH] = "\x5d\x05\x20\x31\x00\x08";
uint8_t MESSAGE_UNKNOWN4[MESSAGE_LENGTH] = "\x5e" "ASUS Tech.Inc.";
uint8_t MESSAGE_UNKNOWN5[MESSAGE_LENGTH] = "\x5e\x05\x20\x31\x00\x08";

Thanks for the help here!

[wroberts]

@flukejones @JoshDreamland amazing work guys. Do you think there is a PR in here? These init messages might fix issues for other people with similar hardware, I suppose.

[flukejones]

@wroberts C isn't my strong suit (I'm pretty much exclusively using Rust for systems work these days) and I've barely got time.

It seems that we would be well off to create a wiki page or similar with more in-depth details for each laptop model such as;

• Model number
• Init messages
• Message format
• Aura regions (like individual keys, 3-region, single)
• Patterns

that sort of thing.

I've been considering rewriting this in Rust (yeah I know, it's a crappy trope now) with the goal of running as a daemon to enable coms over a socket, and so enable plain users to set lighting without sudo. You might want to do this with the existing code?

[JoshDreamland]

I can certainly put them in a PR, just like that, but I'm not sure the best angle to go about it. Do we want a new rogauracore init command that just sends those messages?

I'm skeptical of putting them in by default (eg, at startup) until we answer a couple questions:

1. Does it hurt in any way to send those init messages at arbitrary times? What I don't want is to break the tool for other people by, eg, always sending it.
2. Those messages are actually paired with replies. I like to think it's a handshake that happens between the software (ArmouryCrate) and firmware. I have no idea the repercussions of sending the wrong second/third message in that sequence. Will it break for anyone?

Also, to clarify, the extra APPLY call does not matter on your machine, Luke?