search

ChimeraOS / linux-chimeraos

Stable linux kernel patched for gaming
GNU General Public License v2.0
18 stars 15 forks source link

hid-asus disables the ROG ALLY RGB LEDs, prevents OpenRGB from working #15

Closed CalcProgrammer1 closed 1 year ago

CalcProgrammer1 commented 1 year ago

I'm not sure exactly where the problem lies, if this is with OpenRGB missing some initialization or if hid-asus is setting some RGB disable flag that isn't set in Windows or with the unmodified kernel, but with this kernel (on Arch) the LEDs shut off while booting Linux and remain off even if I try to change them with OpenRGB. I then tried to save a mode change and it looks like that actually did persist when I power cycled, but again went off before Linux finished booting. I blacklisted hid-asus and rebooted into Windows which reset the LEDs to working (and OpenRGB was able to control them there) then rebooted back into Linux with chimeraos kernel and the LEDs stayed on because hid-asus did not load. I can successfully control the LEDs now.

I did not observe this behavior with the stock Arch kernel last I tested, but I can test again with the latest 6.4 kernel to verify this.

Edit: In stock Arch 6.4 kernel

[adam@Adam-ROG-Ally ~]$ uname -a Linux Adam-ROG-Ally 6.4.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 11 Jul 2023 05:13:39 +0000 x86_64 GNU/Linux

The hid-asus module does not load and the lights remain on (not blacklisted).

CalcProgrammer1 commented 1 year ago

Going to try to remove the keyboard backlight flag from the Ally hid-asus block.

CalcProgrammer1 commented 1 year ago

My change worked, the lights don't automatically turn off but hid_asus is loaded and I can still control them with OpenRGB.

CalcProgrammer1 commented 1 year ago 
diff --git a/linux/0003-asus-ally-asus-hid-6.3-v2.patch b/linux/0003-asus-ally-asus-hid-6.3-v2.patch
index 8c763c6..20beb28 100644
--- a/linux/0003-asus-ally-asus-hid-6.3-v2.patch
+++ b/linux/0003-asus-ally-asus-hid-6.3-v2.patch
@@ -25,7 +25,7 @@ index d1094bb1aa42..47fb048bb5fd 100644
          QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
 +      { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
 +          USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY),
-+        QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
++        QUIRK_ROG_NKEY_KEYBOARD },
        { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
            USB_DEVICE_ID_ASUSTEK_ROG_CLAYMORE_II_KEYBOARD),
          QUIRK_ROG_CLAYMORE_II_KEYBOARD },
Samsagax commented 1 year ago

Great find! Thanks I'll modify the patch for next builds.

jlobue10 commented 11 months ago

Sorry to re-address and try to re-open this issue, but I think we actually want to revert this change. Without this QUIRK_USE_KBD_BACKLIGHT quirk I do not have control of the LEDs with OpenRGB in Nobara, but if I re-enable this quirk and recompile the kernel and modules, I do gain control of the LEDs with OpenRGB (0.9 AppImage version). They do go dark during initial boot and do appear that control is lost, but it's actually just that the OS keyboard brightness is set to 0. In KDE Plasma it's easy to turn this up and regain control of the LEDs, and switching modes in OpenRGB does work. At least one other user has confirmed this working for them as well. This also survived a cold boot for me.

Screenshot_20230924_212835

CalcProgrammer1 commented 11 months ago

I'm also up for adding brightness control into OpenRGB. Regardless of the decision here I think it's a good idea. I think it's best to have all control in the same place.

On Sun, Sep 24, 2023 at 11:35 PM jlobue10 @.***> wrote:

Sorry to re-address and try to re-open this issue, but I think we actually want to revert this change. Without this QUIRK_USE_KBD_BACKLIGHT quirk I do not have control of the LEDs with OpenRGB in Nobara, but if I re-enable this quirk and recompile the kernel and modules, I do gain control of the LEDs with OpenRGB (0.9 AppImage version). They do go dark during initial boot and do appear that control is lost, but it's actually just that the OS keyboard brightness is set to 0. In KDE Plasma it's easy to turn this up and regain control of the LEDs, and switching modes in OpenRGB does work. At least one other user has confirmed this working for them as well. This also survived a cold boot for me.

[image: Screenshot_20230924_212835] https://user-images.githubusercontent.com/9971433/270229251-43a7ab06-ba75-4cae-aa45-b1fbe472f2de.png

— Reply to this email directly, view it on GitHub https://github.com/ChimeraOS/linux-chimeraos/issues/15#issuecomment-1732893134, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIAY7GRK37KXMGV2M563NLX4ECXRANCNFSM6AAAAAA2K2L5IU . You are receiving this because you authored the thread.Message ID: @.***>

jlobue10 commented 11 months ago

I think brightness control in OpenRGB would be a great addition (great software btw).

But yes, this kernel patch change should be reverted. Having consistent LED control now is so nice.

BoukeHaarsma23 commented 11 months ago

I have reverted it here: https://github.com/ChimeraOS/linux/commit/15e5c2dfe7310643c419ed7d159e510ad66dcda4