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?

[flukejones]

I just did a few cold-boots to test things properly.

1. It appears I can send just 0x5d, 0xbf and not all those strings (MESSAGE_UNKNOWN only)
2. I can send that message before any command and everything works fine
3. The extra APPLY doesn't seem to matter at all

Looks like the controller on this machine ignores any excess calls. It also seems to retain the last colour mode but not brightness.

[JoshDreamland]

Interesting... my machine also doesn't care when I send that message. Could be safe. It is the first meaningful message ArmouryCrate sends, so if that's all it takes, maybe we could always send it.

Or, out of an abundance of caution, maybe we should instead create --init1, --init2, and --init3 to send those messages, document that they're experimental and we're looking for feedback, and see if we can get some more data on them.

To clarify, my best guess is that the first message stands alone, the next two are step one of a handshake, and the next two are step two. I am grasping at straws, there, though.

[flukejones]

It's a strange thing to send though. It definitely doesn't make any difference to my laptop if those messages are sent at all, only seems to require the first one.

"\x5d" "ASUS Tech.Inc.";
"\x5d\x05\x20\x31\x00\x08"

with a small change to the first byte to 0x5e... It's an odd thing. Either way, it didn't seem to matter to this laptop. If others require it, it might not hurt to send all times.

Another note: regarding doing something like a daemon using systemd, I guess here an extra CLI option for --init wouldn't be a silly idea at all.

[flukejones]

It seems that perhaps the controller for LED retains a small charge that isn't dissipated unless the laptop is off for longer than 10 seconds. It turns out I require that full set of messages after all.

[JoshDreamland]

Hm. Perhaps the first message is WAKE and the next two pairs control version modes. I am also wondering if your machine doesn't have a third pair of messages. Guess it doesn't really matter, as we wouldn't be able to use them. I suspect they'd be for enabling per-key lighting messages. But you do need all five, not just the first three?

[flukejones]

Just tested properly. I need only the first 3 messages. But also sending all 5 doesn't hurt anything either.

Multi-LED effects don't work, so I'll definitely try to capture that initialization stuff now.

[flukejones]

Finally got decent capture of startup from installing the Armoury Crate - turns out whenever I uninstalled it, it wasn't cleaning up after itself and left some services behind. Looks like it sends only:

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";

and those are sent multiple times. Unsure if the sequence shown matters though, or the count.

1. A new packet? \x5d\xb9
2. MESSAGE_UNKNOWN4+5
3. MESSAGE_UNKNOWN2+3
4. MESSAGE_UNKNOWN2+3
5. MESSAGE_UNKNOWN4+5
6. MESSAGE_UNKNOWN2+3
7. MESSAGE_UNKNOWN2+3

And yeah, it does continuously send commands to the controller to make effects like rainbow work. But I'm also certain that there are some built-in modes that don't need that, and I'm certain rainbow was one.

EDIT: Cleaned up some misunderstandings. Also can confirm that a rainbow mode does work without continuous input, but the mode given by the rogauracore for rainbow does not work. I can't test other stuff until I cold boot and that may be a while as I have quite a bit of work to do first.

crate-spam.pcapng.gz

[JoshDreamland]

The rainbow mode in #26 may work for you, Luke.

I'm seeing more and more reports that this WAKE/INIT message is the fix for people, so we should probably push it out in some form or another. Thinking we should just include all of the above as separate commands, and also change the rainbow commands to rainbow1 and rainbow2, and just let people figure out what works for them.

[flukejones]

I decided to dive in and have a real good tinker with things - ended up writing my own tool in Rust (I don't know C). You might find it interesting [link]. I mapped out all the bytes for the built-in LED modes, and that data is in the comments.

I'm now in the process of implementing a daemon mode to catch the hotkeys and use them for aura control + other missing functions.

[flukejones]

I've posted info in a bugtracker for the Ubuntu kernel [link]

And I've completed a large amount of work on the daemon for controlling aspects of the GX502GW laptop [here].

If people are interested in adding support to this daemon for their laptops I'm willing to help.

[ghost]

@JoshDreamland, @wroberts I think the wake up/init function should be a separate function because looking at the hid-asus.c of the kernel it initialize the keyboard just with (link to kernel source) :

0x5a, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54, 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00

If the keyboard id is in their list of supported devices (link to kernel source), so if the id is being handled already by the hid-asus driver there's no need to call the wake/init because it is "supposedly" initialized, and if not it should be explicitly called in rogauracore. I made a test in this branch and it works with a GA502DU laptop.

[JoshDreamland]

I think the messages required to initialize the keyboard for typing are distinct from those to initialize it for pretty colors. I've noticed that lighting functionality has slowly trickled its way into the kernel code, but I don't expect them to want to support all this RGB hoo-hah. It's possible we could get them to add the init and brightness messages, though. I just don't want to go open that can of worms; no time for it, personally.

[swagglepuf]

@qquique I tried your branch for testing for the GA502DU and it doesn't seem to want to work. What distro are you using it on. I am currently on manjaro and tried it with kernel 5.7 and it didn't work. I have a patch applied to 5.4 and 5.6 that enables the function keys to adjust brightness like in windows. I am looking for an easier approach rather than patching and compiling a kernel every 1-2 weeks. I am going to install kernel 5.5 and try that seeing as how it isnt a rc kernel.

[ghost]

@qquique I tried your branch for testing for the GA502DU and it doesn't seem to want to work. What distro are you using it on. I am currently on manjaro and tried it with kernel 5.7 and it didn't work. I have a patch applied to 5.4 and 5.6 that enables the function keys to adjust brightness like in windows. I am looking for an easier approach rather than patching and compiling a kernel every 1-2 weeks. I am going to install kernel 5.5 and try that seeing as how it isnt a rc kernel.

Using arch, the branch is confirmed to work by two other people using ubuntu 1, 2, fn keys plus brightness only works with this patch idk if is the same that you have.

pd: pr sent

[swagglepuf]

@qquique I tried your branch for testing for the GA502DU and it doesn't seem to want to work. What distro are you using it on. I am currently on manjaro and tried it with kernel 5.7 and it didn't work. I have a patch applied to 5.4 and 5.6 that enables the function keys to adjust brightness like in windows. I am looking for an easier approach rather than patching and compiling a kernel every 1-2 weeks. I am going to install kernel 5.5 and try that seeing as how it isnt a rc kernel.

Using arch, the branch is confirmed to work by two other people using ubuntu 1, 2, fn keys plus brightness only works with this patch idk if is the same that you have.

pd: pr sent

I guess I missed the part about downloading the other package, will try it now and report back. Can confirm this does in fact work. Currently running pop 20.04 with xanmod 5.6.10.