OpenRGB

[lorenzvee]

Hello and thanks for your hard work.

I'm using your work for the last week but I could not get OpenRGB to work. (i2c error)

Is it working for you?

Right now I'm using the version 6.5.3.

Thanks

[jlobue10]

No, I've never been able to get the LEDs to work with OpenRGB either (and I'd like to). The device seems to be detected in OpenRGB 0.9, but I'm unable to change LED state from OpenRGB. Since I'm dual-booting, in Linux the LEDs are just doing what the last configuration left them as from Armoury Crate in Windows.

I think it would be best to open an issue on the OpenRGB GitLab page. My few attempts to get help in the Discord felt futile (met with non-answer answers and nothing of value to check / troubleshoot).

The UDEV rule exists for me at /usr/lib/udev/rules.d/60-openrgb.rules. I'm assuming this is how OpenRGB sees the device as the ROG ALLY. It still just doesn't allow me to change the LEDs, so something is missing. I see the HID device in the Hardware IDs tab too that he references in his Windows video about OpenRGB with ASUS ROG ALLY. [0B05:1ABE U=0076 P=FF31 I=2] . I'm uncertain what to do with that information, but that seems to be important (from his video).

[lorenzvee]

Thanks for your reply.

Yes i should try to contact the develover to find out what's happening and report back if I find something.

Keep it up with your good work.

[jlobue10]

I'm cautiously optimistic that my kernel patch for the LED fix MAY fix the issue. It's live now if you do the custom 6.5.4 kernel compile and install to test it.

The udev rule is required.

[lorenzvee]

Thanks
I am gonna compile it and get back to you

[jlobue10]

One person said it's not working for him. This is so strange. I'm asking some Asus experts to see about fixing the patch. My LED init may be partial or incorrect. It's just really strange that it works for me and not others so far. Work is ongoing on my end.

[jlobue10]

LEDs do work with latest 6.5.5 RPMs. Basically the side buttons patch from the ChimeraOS devs needed to be reverted to enable the keyboard backlight. LEDs need to still be enabled from within Windows Armoury Crate until we figure out how to send that enable USB packet in Linux.

[lorenzvee]

Hello
Yes I can confirm that i was able to change led color with openrgb.
I noticed that after a sleep/resume (systemctl suspend or by pressing the power button with handygccs) i could not change the color anymore.
After a reboot i can change the color.
I tried also with "sudo" without success.
Thanks for your hard work.

[jlobue10]

No problem. This one was definitely a bit tricky to narrow down as I didn't actually see the "fix" until a full kernel recompile with the modifiedpatch. It's definitely nice to have these LEDs working though.

As for sleep in general, it is still very much FUBAR. To be fair, sleep is mostly broken in Windows too. It's a bit complicated of a mess to unravel and solve, but I know multiple people in the ChimeraOS discord are at least looking into it. The N-Key device (side buttons and LEDs) is completely lost during sleep for most ALLYs. This device does come back after a second sleep and resume, but I think LEDs are still lost after sleep until a reboot for now.

[lorenzvee]

Yes i'm following you and the others on the chimeraos discord and honestly i'm very happy that you all the others are trying to find a solution to make this device work.

[jlobue10]

Closing this as completed for now. Re-adding the keyboard backlight quirk (into side button kernel patch) fixes LED control in OpenRGB (but this requires a properly patched kernel to take effect).