asusctl/rog-control-center were just updated to version 6.1.0 and now require the asus_armoury kernel module for much of their functionality (most importantly for me, battery charge limiting), which is currently not upstreamed and requires installing the linux-g14 kernel, either from AUR or from the additional repository ASUS Linux project provides. Unfortunately, a standalone dkms version of the module is not available, so a custom kernel is the only option.
Given Cachy’s willingness to include yet to be upstreamed kernel patches for enhanced hardware support and the fact that it already provides prebuilt asusctl/rog-control-center in its repositories (as opposed to having to install them from AUR on pure Arch) it would be really nice to have this driver land here early as well. Thanks!
Small update: as it turns out, using the asusctl utility or manually editing /etc/asusd/asusd.ron allows to set a charge limit (that’s applied on boot) just fine; it seems like it being unchangeable in ROG Control Center GUI unless the asus_armory module is available is a mistake. Nonetheless, the driver would be nice to have for other features, like controlling panel overdrive.
We’re considering inclusion of asus-armoury for 6.14. The patchset will likely be added around 6.14rc2 or 6.14rc3 when Luke’s master branch calms down a bit in terms of activeness (as indication that things are probably stable at that point).
I myself currently running EndeavourOS wanting to try out CachyOS just found your thread. I run an Asus TUF laptop, currently on the LTS kernel of EOS.
I’ve tested the RC kernel and can confirm that asus_armoury module is included and gets loaded! However, there’s currently another problem - asusd fails to start with the following error:
> systemctl start asusd.service
Job for asusd.service failed because the control process exited with error code.
See "systemctl status asusd.service" and "journalctl -xeu asusd.service" for details.
> journalctl -u asusd.service -b0 --no-hostname
Feb 14 22:17:01 systemd[1]: Starting ASUS Notebook Control...
Feb 14 22:17:02 asusd[2269]: [INFO asusd] daemon v6.1.2
Feb 14 22:17:02 asusd[2269]: [INFO asusd] rog-anime v6.1.2
Feb 14 22:17:02 asusd[2269]: [INFO asusd] rog-slash v6.1.2
Feb 14 22:17:02 asusd[2269]: [INFO asusd] rog-aura v6.1.2
Feb 14 22:17:02 asusd[2269]: [INFO asusd] rog-profiles v6.1.2
Feb 14 22:17:02 asusd[2269]: [INFO asusd] rog-platform v6.1.2
Feb 14 22:17:02 asusd[2269]: [INFO asusd] Product family: ASUS TUF Gaming A15
Feb 14 22:17:02 asusd[2269]: [INFO asusd] Board name: FA507NV
Feb 14 22:17:02 asusd[2269]: [INFO config_traits] Parsed RON for "asusd::config::Config"
Feb 14 22:17:02 asusd[2269]: Error: MissingFunction("asus-nb-wmi not found")
Feb 14 22:17:02 systemd[1]: asusd.service: Main process exited, code=exited, status=1/FAILURE
Feb 14 22:17:02 systemd[1]: asusd.service: Failed with result 'exit-code'.
Feb 14 22:17:02 systemd[1]: Failed to start ASUS Notebook Control.
I’m not sure what’s causing it and loading the asus-nb-wmi module manually does not fix it. @naim any idea if it’s something on my end or just RC kernel not being fully ironed out?
What happens if you download asusctl and supergfx and see if it makes any difference? Please take a timeshift or snapper before doing it. You need to of course add the g14 aur
asusd is a part of asusctl, which is what I’m reporting on in the first place… Also, these are already available in cachyos repositories (and in regular AUR, for that matter, g14 repo is only needed if you want pre-built packages outside of cachyos).
The linked issues seems mostly unrelated (as they concern either the module failing to load or lacking a tunable) and 6.14 release candidate kernel naturally includes whatever fixes landed in 6.13 anyways.
A user wrote in the Garuda forum that he had checked supergfxctl and asusctrl.
This is his result:
supergfxctl
Xorg is no-longer supported (but supergfxd still works with it)
asusctrl
X11 support
X11 is not supported at all, as in I will not help you with X11 issues if there are any due to limited time and it being unmaintained itself.
I’m not using X11 either way… asusctl and rog-control-center rely on the asusd daemon (part of the asusctl project) to implement functionality, so it failing to start renders both of these unusable. Haven’t specifically checked if supergfxctl and its corresponding daemon still work.
Thanks! I saw a couple of users get crashes but I’ve never gotten any logs from any of them. FWIW I got the same logs but I don’t have an ASUS so of course the logs don’t really mean anything. I’ll forward this to Luke, I appreciate the logs.
FWIW, it seems that things are working on my end now on RC kernel. Not sure what changed, aside from updating to asusctl 6.1.4, which doesn’t seem to contain any relevant fixes. I’ve had some strange problems with asusd failing to start before, so it may be some kind of a race condition during boot or something…
I have no idea what this means but the armory crate has a reputation for being cancerous spyware. I got a rog chakram mouse with a cool little thumbstick on the side. It didn’t work. But it was nearly impossible to get rid of the permanently running armory crate processes that it came with on windows. A bunch of people experienced the same thing.
This is about an open-source reimplementation of its functionality on Linux. For better or worse, the actual application from ASUS will most likely never work outside of Windows.
I have zero idea how necessary or helpful it would be to have it included in the kernel, but that whole experience left such an awful taste in my mouth that I question ASUS as a whole. Like I said, bunch of people went through that, it’s a verifiable thing. I would vote hell no, but it being an open source version sounds slightly better, I guess
This is really just a new and improved userspace interface; functionality itself has already been in the kernel for a good while.
Worrying about it because it is an open-source reimplementation of terrible software by ASUS is like worrying about Linux+WINE because it’s an open-source reimplementation of Windows of sorts. Code has no direct relation to the original software in both cases too.
Being a kernel module, this won’t load unless you have relevant ASUS hardware (or load it manually). It’s just like any other driver.
And for end users it means that toggles for a few things like panel overdrive will be available once again. That’s it.
The armoury crate for Windows and the ASUS armoury driver in Linux are two completely separate things. The ARMOURY driver is necessary for the latest down to 2022 models ASUS laptops to work.
