Arch Linux, ASUS TUF FX505DU: RGB confirmed working, but causes serious kernel malfunction about faustus HOT 7 CLOSED

I'm going to update BIOS to the latest version (310) and will report shortly, even though I highly doubt it's gonna help - none of the above problems ever showed up without Faustus being loaded.
UPD: updated BIOS to 310.
Installed faustus-dkms-git from AUR, now it simply gets stuck with a black screen when resuming from suspend, not responding to any actions at all, closing the lid doesn't make it suspend again. Fan and rgb control works. Same if built and inserted manually with @yaliv's patch for DMI.
UPD 2: ended up with an unresponsive black screen again after about a dozen suspends, suspecting conflicts between faustus and the proprietary nvidia driver. It was stuck like this for at least 4 hours.
UPD 3: after yet another failed waking up with a black screen, I had to turn it off and on again, and while I was typing in my password in sddm, the screen turned into THIS:

And after another reboot it just failed to start, showing various debug info and errors, but yet another reboot fixed it (I was expecting the error to repeat after a reboot, so I didn't take a photo). I don't know what to expect now.
There is also a possibility that my DKMS build was built incorrectly after all. Applying the paatch mentioned in #12 just in case. Will report if it works this way later.
UPD 5: The patch did NOT help. The machine is stuck with a black screen again after suspended, does not react to keyboard.

from faustus.

Seems working fine for me too now after several updates.
Had the laptop stuck with 100% cpu load right after resuming a couple of times, but otherwise it works just fine. I guess we can call it working on FX505DU now.

from faustus.

New info: seems to cause recursive boot fails, suspend frequently fails to resume or just takes a very long time (over a minute) on FX505DU.304. Sometimes causes one CPU core (CPU#5) to freeze on boot and it doesn't come online until rebooted with no driver loaded. Sometimes may cause filesystem corruption on HDD for an unknown reason, possibly due to shutting down too early.
RGB keyboard seems to work, but with the brightness issue in static mode. I think all of the above issues are too much for just the RGB control.
Fan control works.
@yaliv, please report if you have any of the above issues.

from faustus.

@k1-801 as you know, I use BIOS version 308. That might be case.
As I update the BIOS of my TUF laptop several times, I see that Asus always keeps the last 2 versions in their support site:
https://www.asus.com/Laptops/ASUS-TUF-Gaming-FX505DD-DT-DU/HelpDesk_BIOS/
And I can say that this BIOS has the easiest update method I've ever experience. You don't need a USB drive or a Windows to flash the BIOS. You just need a FAT32 formatted partition (e.g. used for /boot/efi). Download the BIOS, extract, copy it to the partition (e.g. call sudo cp FX505DU-AS.308 /boot/efi). Then boot to BIOS and you can flash the update in the Advanced Mode. Just find the file in the partition and the flashing process will start.

Next, I'll tell you what I did and didn't.

I didn't:

• install package faustus-dkms-git (in AUR)
• use the let_it_burn parameter

I did:

• disable original modules (blacklist asus_wmi etc.)
• add FX505DU to the DMI list (see my commit here)
• try build using make --> success
• try build using DKMS --> failed

Failing to build the DKMS module makes it impossible to load on boot. So everytime I boot, I have to call sudo insmod src/faustus.ko to enable the driver.
I can control the keyboard light color by editing set_rgb.sh and run it. The light in static mode is dimmer than in other modes ☹️, same as yours.
Fan control works too. In overboost mode, I can hear some kind of extra fan blowing out.
The driver still works after resuming my laptop from sleep.
But when I resume from hibernate, the keyboard light is hang (static and so bright). Editing set_rgb.sh is useless at first, but changing the brightness (Fn Up & Down) makes the light start to move again 🤷‍♂️

from faustus.

There is also a possibility that my DKMS build was built incorrectly after all. Applying the paatch mentioned in #12 just in case. Will report if it works this way later.

Hi @k1-801, I modified file dkms.conf like in #12 (comment) and now the faustus DKMS module is installed 🎉

$ dkms status
faustus, 0.2, 5.5.6-1-MANJARO, x86_64: installed

Then I made it load on boot and yes, the driver runs flawlessly 😁

from faustus.

UPD 2: ended up with an unresponsive black screen again after about a dozen suspends, suspecting conflicts between faustus and the proprietary nvidia driver. It was stuck like this for at least 4 hours.

Hmmm 🤔 about the Nvidia driver, I use the proprietary one.

$ __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia inxi -G
Graphics:  Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nvidia v: 440.59
           Device-2: AMD Picasso driver: amdgpu v: kernel
           Display: x11 server: X.Org 1.20.7 driver: amdgpu,nvidia resolution: 1920x1080~120Hz
           OpenGL: renderer: GeForce GTX 1660 Ti/PCIe/SSE2 v: 4.6.0 NVIDIA 440.59

As you can see, this driver version has the PRIME Render Offload feature enabled by default, so the primary GPU is AMD iGPU.

$ inxi -G
Graphics:  Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nvidia v: 440.59
           Device-2: AMD Picasso driver: amdgpu v: kernel
           Display: x11 server: X.Org 1.20.7 driver: amdgpu,nvidia resolution: 1920x1080~120Hz
           OpenGL: renderer: AMD RAVEN (DRM 3.36.0 5.5.6-1-MANJARO LLVM 9.0.1) v: 4.5 Mesa 19.3.4

Well then.
You said that you got a black screen frequently. Or you got something like a discolored screen.

I do get those screen errors, but not too often. One thing to note is that they happen even when I don't have faustus DKMS module installed.
Perhaps the problem is with the kernel version 🤷‍♂️
I used kernel 5.4 before and today I upgraded to 5.5.

I don't have some heavy programs loaded at boot, so the boot time is often quick.
Sometimes I got a black screen or a discolored screen (after SDDM), so the best thing I can do is forcing my laptop to power off.

When resuming from sleep, it always takes a long time but at least the session is fine. I can type my password and continue my work.

By the way, I have this value in /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_backlight=none apparmor=1 security=apparmor resume=UUID=fc6ff57d-67d0-48e8-b348-a4fd3eae0c29 udev.log_priority=3"

The resume parameter points to my swap partition. It is particularly useful for resuming from hibernate. Possibly useful for resuming from sleep too? Who knows.

from faustus.

Wow, resuming from sleep seems quick now with kernel 5.5 🎉

from faustus.