-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hid-asus disables the ROG ALLY RGB LEDs, prevents OpenRGB from working #15
Comments
Going to try to remove the keyboard backlight flag from the Ally hid-asus block. |
My change worked, the lights don't automatically turn off but hid_asus is loaded and I can still control them with OpenRGB. |
|
Great find! Thanks I'll modify the patch for next builds. |
Sorry to re-address and try to re-open this issue, but I think we actually want to revert this change. Without this |
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
<#15 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIAY7GRK37KXMGV2M563NLX4ECXRANCNFSM6AAAAAA2K2L5IU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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. |
I have reverted it here: |
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).
The text was updated successfully, but these errors were encountered: