can't run ./set_rgb.sh in fx505dy about faustus HOT 14 OPEN

Hi, please check output of sudo dmesg | grep faustus and check whether you actually have the module loaded in lsmod | grep faustus. You should not create any directories manually in sysfs, they should have been created automatically on module load.

from faustus.

I have the fx505dy and I'm fairly certain the keyboard backlight has only red LED's.

from faustus.

Hi, here are the outputs

sudo dmesg | grep faustus:

[ 3.313124] faustus: loading out-of-tree module taints kernel.
[ 3.313158] faustus: module verification failed: signature and/or required key missing - tainting kernel
[ 3.313508] faustus: DMI checK: FX505DY
[ 3.313665] faustus: Initialization: 0x1
[ 3.313714] faustus: BIOS WMI version: 9.0
[ 3.313748] faustus: SFUN value: 0x21
[ 3.313750] faustus faustus: Use DSTS
[ 3.313750] faustus faustus: Enable event queue
[ 3.315321] input: Asus WMI hotkeys as /devices/platform/faustus/input/input15
[ 3.315492] faustus: Number of fans: 0
[ 271.537803] faustus: Set fan mode: 1
[ 2105.218101] glue_helper input_leds snd hid_multitouch serio_raw wmi_bmof k10temp cfg80211 soundcore asus_wireless mac_hid sch_fq_codel faustus(OE) sparse_keymap parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c dm_mirror dm_region_hash dm_log usbhid hid_generic amdgpu chash amd_iommu_v2 gpu_sched i2c_algo_bit ttm nvme drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci i2c_piix4 libahci drm r8169 realtek nvme_core wmi i2c_hid video hid

lsmod | grep faustus:

faustus 36864 0
sparse_keymap 16384 1 faustus
wmi 28672 2 faustus,wmi_bmof
video 49152 1 faustus

the function key for the fan speed is working, I can also control the keyboard backlight intensity using the function keys.

from faustus.

I have the fx505dy and I'm fairly certain the keyboard backlight has only red LED's.

Hi robeirne, my keyboard does cycle between different colors, its a bit annoying since I only want a static color.

from faustus.

Ok, so it does load but doesn't load the RGB backlight control. Fun thing being, is that I also find conflicting accounts about whether this laptop does or does not have RGB (detectable by transparent WASD keys?). A couple of things to check here: 1) do you have USB devices from Asus in lsusb output? 2) are you running latest BIOS version available? 3) related to 2nd question, did it ever work on Windows (if you tried)?

If this won't help then I need to look on DSDT or you can check what is the implementation of DSTS 0x00100056 and 0x00100057 methods.

from faustus.

I can confirm that it has RGB backlight.

here are the output from lsusb:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 003 Device 002: ID 13d3:3530 IMC Networks
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 13d3:56a2 IMC Networks
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I have FX505DY.315 bios version

There is a pre-installed windows when I bought my laptop, and I tried to control the RGB successfully using TUF Aura Core

I also checked on this directory /sys/class/leds/ it does not contain faustus::kbd_backlight instead it contains asus::kbd_backlight

from faustus.

That's odd that Asus would make two models with the same name with different hardware specs. I definitely have a FX505DY and I definitely only have red keyboard lights. I don't have the clear WASD keys like yours.

BIOS Information
        Vendor: American Megatrends Inc.
        Version: FX505DY.309
        Release Date: 04/25/2019

Edit: lsusb with nothing attached via USB:

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 13d3:3530 IMC Networks Bluetooth Radio 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 13d3:56a2 IMC Networks USB2.0 HD UVC WebCam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

from faustus.

It doesn't look like there are USB controllers for RGB there. So it must be WMI. Can't help you without DSDT though.

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml

faustus::kbd_backlight instead it contains asus::kbd_backlight

That part of README, was wrong, thanks for noticing!

from faustus.

BIOS Information
        Vendor: American Megatrends Inc.
        Version: FX505DY.309
        Release Date: 04/25/2019
--
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: FX505DY
        Version: 1.0

fx505dy_309_dsdt.aml.gz

from faustus.

It doesn't look like there are USB controllers for RGB there. So it must be WMI. Can't help you without DSDT though.

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml

faustus::kbd_backlight instead it contains asus::kbd_backlight

That part of README, was wrong, thanks for noticing!

Here is the output from sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
dsdt.aml.gz

from faustus.

Ok, so I've looked into DSDTs you've provided,
a) you really do have same BIOS
b) the DEVS (device set) devices for RGB keyboard are there in both of your BIOSes and they definitely do something very similar or even exactly the same as other laptops. But the DSTS (device status) devices don't return the correct status as other laptops do, as they are not even there. Also the implementation is drastically different from other laptops, although the call parameters do look similar.

So I am perplexed at how this can be universally supported at all and what did the engineers think. The question is also what happens if these calls for RGB keyboard for DY would run on laptop without RGB and how bad would that be.

Can't really help you much further without physical device. It would be great if you could look into it and play with it yourself if you know what you're doing. Fair WARNING though, the disclaimer in README applies, you can accidentally BRICK something. More practically you may oops you kernel more than once, so make sure you save your data. Below is what you could try.

You can disassemble the DSDT with iasl dsdt.aml from acpica-tools and then search for the device IDs 0x00100056 0x00100057, you see them calling SRKZ / SRLW. Comparing to my current implementation these do look almost exactly the same. DSDT of other laptops do provide more specifics to the expected values there.

SRKZ

            ZOPC = (Arg0 & 0xFF) // (persistent ? 0xb4 : 0xb3)
            ZEFC = (Arg0 >> 0x08) // mode_byte (EFfeCt?)
            ZCLR = (Arg0 >> 0x10) // red
            ZCLG = (Arg0 >> 0x18) // green
            ZCLB = (Arg1 & 0xFF)  // blue
            ZPED = (Arg1 >> 0x08) // speed_byte (sPEeD)

SRLW:

            WOPC = (Arg0 & 0xFF) // magic byte (0xbd?)
            WSBC = (Arg0 >> 0x08) // flags (?)
            WENB = (Arg0 >> 0x10) // persistent ? 0x01 : 0x00  (enable?)

The CoLor Red etc. is pretty self explanatory evidence that this might all work out of the box, but the effect and magic bytes etc. is where I have my doubts, this might require some brute forcing. What I would suggest if you are motivated, try commenting out the DSTS check at https://github.com/hackbnw/faustus/blob/master/src/faustus.c#L1130 on 1130 through 1144 and try playing with set_rgb script and/or arguments on https://github.com/hackbnw/faustus/blob/master/src/faustus.c#L1021 manually and see what happens.

Still if it works I don't know how to integrate this universally other than maybe adding another parameter likes of let_it_burn to the module.

from faustus.

@hackbnw

this worked for me, i have the same laptop as him asus tuf FX505Dy.315.
i had the exact same problem. and removing the 2 chunks that check to see if you have an rgb keyboard on line 1130 and 1144 in the Faustus.c file. Then rmmod the wmi and stuff again and make the files again and make dkms again gives you the folders that are needed. Only then OpenRGB finds the keyboard and everything works as it should.

you can either nano into the settings files directly or let openrgb do it for you.

from faustus.

@Shadefix Can you upload here your faustus.c file so I can compare with the original? Thanks!

from faustus.

@hackbnw I have commented out lines 1128 through 1144. Followed what @Shadefix did and it worked well with OpenRGB. We can now close this issue.

Thanks to both of you!

from faustus.