Most of faustus functionality is now in mainline kernel

rublag commented 4 years ago

These version include all the new patches except LEDs. Multicolor LED kernel API is still in development.

5.7.11
5.8
5.4.54

Path to driver sysfs:

/sys/devices/platform/asus-nb-wmi

Someday I will port rgb API from faustus driver

cromerc commented 4 years ago

Does the new version expose the fan control? Does it have your patch which allows polling the fan state?

ferretwithaberet commented 4 years ago

@rublag can you please answer @cromerc's question? I want to know that too.

rublag commented 4 years ago

@ferretwithaberet @cromerc There is fan control. There is no polling support. I hope, in the next month I'll manage to make a patch set for correct temperature reading and polling.

cromerc commented 4 years ago

@ferretwithaberet @cromerc There is fan control. There is no polling support. I hope, in the next month I'll manage to make a patch set for correct temperature reading and polling.

Nice, I based all my work on tuf-manager's polling on your patch work, so hopefully your patches get accepted so that it will work out of the box on the mainline kernel.

hackbnw commented 3 years ago

@rublag thanks for your great work with patches and opening the issue. I've pinned it as I also think it is important to note. The only thing missing is RGB control (because of multicolor framework, as mentioned). I think though it is good to have reference dkms driver to reduce barrier of entry to kernel development and as a platform for experimenting. The faustus is compilation from the following files from linux source:

drivers/platform/x86/asus-wmi.c (main driver code)
drivers/platform/x86/asus-wmi.h (main driver code header)
drivers/platform/x86/asus-nb-wmi.c (sparse keymap)
include/linux/platform_data/x86/asus-wmi.h (WMI devices constants)

after forking and modifying the code it is straightforward enough to put changes back. That does not help with testing the patch against complete build of mainline kernel, which should still be done in any case.

Refer to the following great resources for reference on the development process and information:

The patches for these drivers should be submitted to the platform-driver-x86 subsystem mailing list.

chknatwork commented 3 years ago

Out of curiosity, once this happens, do we need to remove DKMS and the module?

Not sure if having both installed can cause issues.

cromerc commented 3 years ago

When you install this module it disables/blacklists the one in the kernel. So naturally if you want to use the one from the kernel you need to uninstall this and unblacklist the one from the kernel.

Andy3153 commented 2 years ago

What's the status of this? Do you even need Faustus at all at this point?

cromerc commented 2 years ago

What's the status of this? Do you even need Faustus at all at this point?

Did you even read the full thread before posting?

LED is not in those kernel versions and neither is fan polling. It's just fan speed control.

Andy3153 commented 2 years ago

What's the status of this? Do you even need Faustus at all at this point?

Did you even read the full thread before posting?

LED is not in those kernel versions and neither is fan polling. It's just fan speed control.

I was asking because it's been a while since it's been talked about, and I figured I should ask to check the status

K4R7IK commented 2 years ago

Can anyone tell me difference between fan polling and fan speed control. Also is there a way to only implement RGB functionality with asus-wmi drivers as in the recent updates powerprofilesctl is also introduce which provide a GUI to control the system mode.

cromerc commented 2 years ago

The polling is used to send a message to another software that is listening. In the software TUF-Manager it uses the polling to detect when the fan speed changes and when it changes it shows a notification message that tells the user the new fan speed.

prenex commented 1 year ago

@rublag or anyone. Can you tell me if there is a way to turn on/off "airplane mode" on Asus TUF FX505DT.306?

I have a very crazy reason: battery was nearly flat out and I turned off the machine (shutdown -h now) but while it turned of it also started to auto-susped or auto-hybernate, but the shutdown finished (or maybe power lost?). Now I have no wifi as always in airplane mode...

I tried these:

BIOS reset to defaults
fully charged, etc.
of course tried supposed hotkey for it (FN+F12)
I read around a LOT on the internet as I am developer and see the whole ACPI magic below the OS at least shallowly so I guess I do not have this button. Currently using mainline kernels corresponding wmi - but considering this in case its safe. Or might consider this anyways and look if it works..

Is there some sysfs command that would do the thing or at least test if this is just a missing hotkey or a missing functionality or what? Should I try this faustus (not interested much in LED cycling but why not? might try it anyways) or do you have experience that maybe a firmware update would reset this bad state? I did not do any updates on software side so I think it is some value that got stuck in...

Also would love to know more about this. Is there some kind of flash where some settings (like airplane mode on/off from last time or what keyboard cycling setup I have, etc) are stored and thus that is where this got stuck in and not letting me out of airplane mode?

I also have some division by zero ACPI messages that does not look good, but I saw them with some guy on the net who happily use the machine with it so maybe it is nothing related though...

dec 11 16:26:00 magosit-laptop kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GPP0.SWUS], AE_NOT_FOUND (20220331/ds>
dec 11 16:26:00 magosit-laptop kernel: ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20220331/psobject-220)
dec 11 16:26:00 magosit-laptop kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GPP0.SWUS.SWDS], AE_NOT_FOUND (202203>
dec 11 16:26:00 magosit-laptop kernel: ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20220331/psobject-220)
dec 11 16:26:00 magosit-laptop kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buff>
dec 11 16:26:00 magosit-laptop kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buff>
dec 11 16:26:01 magosit-laptop kernel: ACPI Error: Divide by zero (20220331/utmath-478)
dec 11 16:26:01 magosit-laptop kernel: ACPI Error: Aborting method \_SB.ATKD.WMNB due to previous error (AE_AML_DIVIDE_BY_ZERO) (202203>
dec 11 16:26:02 magosit-laptop kernel: 
dec 11 17:13:31 magosit-laptop dhcpcd[867]: dhcp6_openudp: Address already in use
dec 11 17:13:31 magosit-laptop dhcpcd[867]: ps_inet_startcb: dhcp6_open: Address already in use
dec 11 18:44:54 magosit-laptop kernel: Uhhuh. NMI received for unknown reason 2c on CPU 1.
dec 11 18:44:54 magosit-laptop kernel: Dazed and confused, but trying to continue

I think the NMI is unrelated and likely after I booted (currently on cable... wifi was very well worked before!) and the NOT FOUND kind of ACPI bugs I hear "is quite usual for AMD processors" which I have. The ACPI region not covering command/resp buffer sounds bad and divide by zero also sounds bad. TPM is likely some trusted platform shit and hopefully totally unrelated too however, except if those bug override something because of small buffer but I doubt so.

I am not even sure if these errors at all related to my issue though as I did not look for ACPI things before in journalctl so cannot know. I guess I will try this faustus thing as FX505DT seems like pretty succesful with people except they never try my exact BIOS version.

I have this DSDT too in case its needed. I also have acpi_call installed in case there would be something I could write into it. I do not have winblows or other systems for this machine to turn the mode back to normal... Any help is appriciated!

acpi.zip

EDIT: asus-wireless.ko is also loaded and have no idea if that helps in any ways, but that is the thing I would normally guess try the airplane mode things.. but maybe only for older asuses or maybe it does but wmi and acpi already not helping it anyays

prenex commented 1 year ago

What I suspect - with my very limited and shallow knowledge related to this after readin - is that in the DSDT the following device is relevant:

    Device (ASHS)
    {
        Name (_HID, "ATK4002")  // _HID: Hardware ID
        Method (HSWC, 1, Serialized)
        {
            If ((Arg0 < 0x02))
            {
                OWGD (Arg0)
                Return (One)
            }
         ....
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If ((OSYS >= 0x07DC))
            {
                Return (0x0F)
            }
            Else
            {
                Return (Zero)
            }
        }

        Method (OWGD, 1, NotSerialized)
        {
            ^^ATKD.WLED (Arg0)
            ^^ATKD.BLED (Arg0)
            ^^ATKD.WMXC (Arg0)
        }
        ....

and status command seems really simple that just returns some OK for OS-es bigger than random something and zero otherwise and this other random command that do some ops on leds might maybe be useful with acpi_call? I mean that kind of how I shallowly understand this...

Only once/twice (very close to each some year ago) I did some kernel debugging around or in modules and it was totally not acpi at all, but some graphics card things with help too... So I might be totally wrong, but because this value I found in "asus-wireless.c" in device IDs and suspect that would control airplane if it could... maybe there is something related. But will look device ids here too of course.

prenex commented 1 year ago

#define | ASUS_WMI_DEVID_WLAN   0x00010011
#define | ASUS_WMI_DEVID_WLAN_LED   0x00010012

I see these being also mentioned in ...Method (WMNB, 3, Serialized)... like:

                    If ((IIA0 == 0x00010012))
                    {
                        WLED (IIA1)
                        Return (One)
                    }

Also as a generally and hopefully useful info for everyone is that I see LED commit here in mainline: https://github.com/torvalds/linux/commit/e305a71cea37a64c7558b8b979f6f08f657d0c3d

So likely those kind of things work in mainline. I also see some other repos, most relevantly this: https://github.com/Ann1kaB/faustus

That seems more recent that this?

In any ways.. some way to turn off airplane mode would be appreciated...

rublag commented 1 year ago

@prenex, did you check simpler possible reasons like rfkill being active or NetwokManager misconfiguration?

N.B. This repo seems abandoned. And the faustus module (if i remember correctly) is essentially asus-wmi and asus-nb-wmi with keyboard backlight color control, gpu sensor reading, and fan sensor reading features added. So I don't think you need it.

prenex commented 1 year ago

rfkill did not show anything... empty json result / empty result. device was not showing up anywhere neither...

really interestingly it got "fixed" yesterday when I blew up a light bulb and all elecrticity went away.... So weird as I about to write to some acpi debug things, but got really sick so still laying and so weird it got fixed but i guess it would be nice if I understand backgroung of this....

Andy3153 commented 1 year ago

@prenex I had a WiFi-related problem a week or two ago as well. I didn't go as deep into the issue as you did, but, for me, the wlan0 interface wasn't showing up anymore, there was no rfkill event for WiFi, and the airplane mode LED was turned on permanently. But, as you said, for me too, it just fixed itself one day. No idea if it's an issue with Faustus or with anything else.

EDIT: Here's where I reported my problem, more details there.

misaka19465 commented 1 year ago

kernel 6.1 has included LED controlling since this and this commit has been merged. It seems that faustus is no longer needed in future kernel versions.

JORGETECH commented 1 year ago

I can confirm I no longer need faustus for my FX505DT laptop running Linux 6.2. But I found the app I was using for setting the keyboard LEDs (Asus TUF Control Electron) no longer works. Does anyone know of an app that works on current kernel?

saracen24 commented 1 year ago

@JORGETECH starting from linux kernel 6.1 asusctl should work. This is a demon and there are GUI applications for it like rog-control-center and rog-aura for RGB keyboards.

K4R7IK commented 1 year ago

I have been using asusctl for while now. Everything works fine expect led controls for FX-705DT.

Andy3153 commented 1 year ago

OpenRGB works perfectly on my FX506HM.

Fan control also just works. Since I want an indicator for what profile is currently on, I just have this script of mine that sends me a desktop notification whenever the mode changes, and I just have it in my autostart as checkFan.sh --in-notification

Kernel version:

$ uname -sr
Linux 6.2.12-zen1-1-zen

hackbnw / faustus

Most of faustus functionality is now in mainline kernel #47