Transmission begins: Hi, fluke here!
With donations from so many, selling another laptop I had (and MSI GS65), plus chipping in some of my own cash I managed to get a GA401QM, complete with AniMe.
And yeah, I've been hacking on it since I got it! So this update will cover much of what I've learned and fixed so far, plus some updates on asusctl and AniMe.
🔗 Project Rename
Not the whole project, whcih is still the
asus-linux umbrella, but the
asus-nb-ctrl daemon project is renamed to
asusctl with all existing tools keeping their names. Quite frankly I was sick of typing
asusd-user is a new user daemon in progress which aims to provide user level setitngs for:
- AniMe sequences
- Keyboard lighting
- Hardware profiles
while the base
asusd will keep basic system settings, a bit like setting defaults if
asusd-user isn't running. The config for
asusd will need to be manually edited once this work is completed as the dbus interface will not save the settings sent (to prevent user settings constantly overwriting).
This is a work in progress and not yet released but you can try it out in main branch.
I've pumped in a ton of work on AniMe.
asusd now has the following capabilities:
- show an action sequence on boot
- show an action sequence on shutdown (TODO: need to inhibit shutdown to allow sequence to complete)
- show an action sequence on wake
asusctl can send a basic image.
asusd-user has support only for anime sequences at the moment. Something of a test run (it works well). I will be changing it so that users can store many sets of configs and select between them.
🔗 AniMe Crate
I split out the bulk of the AniMe specific stuff to a published crate which provides everything possible a consumer might need for interaction with the AniMe display either through USB direct or through the
asusd dbus interfaces.
Supported so far is:
- Sequences of data,
- Data can be:
- Image<scale, rotate, position>
- ASUS style gif
- Plain image type gif
- Create USB HID packets for writing to the device
I'll add extra effects and other goodies over time. One I'd like to add soon is a fade for images and gifs.
Also big thanks to @meumeu for ZephyrusBling which provided a lot of pointers to how to sample images nicely.
NOTE: ASUS style gif means the diagonal gif. You should check out this article for some nice info. In the
asusctl data directory, and in
rog-anime I've included a .png version of the template from that site whcih can be displayed as is to show exactly the dimensions on anime.
Other features to come are:
- Diagonal font and text
- General font and text
- System info for Linux and Windows
- Audio EQ visual for Linux and Windows
- Time+Date display
🔗 RGB Keyboards and other
Some helpful users have provided wireshark captures of the new Strix models with touchpad-numpad, and the extra RGB zones.
So it appears that the device
0x18c6 is the numpad device. I'm unsure of exactly how these combo devices work yet.. There seems to be an on/off switch made of two bytes send to that device, but actually using it I'm yeah, need info.
It's possible that the on/off mentioned is sent along with extra commands on i2c bus. Won't know for sure until a test is jimmied up.
🔗 Extra lighting
On models with numpad as normal combined with RGB per-key, the captures have been umm... captured. Yeah. It's just a matter of mapping them out now.
I'm part way through work to pull the lighting stuff in to an
rog-aura crate now, which will include functionality similar to the anime work above. So users will be able to assign action sequences to individual key lights.
🔗 2021 G14 (GA401Q)
🔗 dGPU always on
As discussed last month, there is a setting in Windows Armory Crate which can turn the dGPU on/off/auto. I've dumped the ACPI tables and found the call that makes this happen, and written a test patch.
Re-enabling the dgpu in Linux with this patch is a 3 step process however.
- echo 0 to the new dev path
- rescan PCI bus
- echo 0 to the new dev path again
The last two steps are required because the ACPI appears to not save the setting unless step one and two are performed to wake things up, then the last step performed so the ACPI call can check things woke correctly then save.
You can also remove the device this way too, but you need to first
rmmod the drivers, then detach the devices from the device tree or you'll get a hard system hang. And anyway once you've done those steps you've pretty much done in software what ACPI was doing - overall the ACPI method seems like a horrible hack ASUS did to do what
asusctl does, but in Windows.
The sole reason for the patch above is to re-enable the device. But I need to find the best way to do so that doesn't require the multiple steps. The first step also requires 5-10 seconds due to a bunch of count-down loops in the ACPI method chain so if this is included in kernel then boot can take extra time (and every time too as the setting won't save unless you do the extra steps).
🔗 Touchpad issues!
So the fix here appears to be to build the
pinctrl_amd module into the kernel permanently. The reason to do so is so that it loads and initialises everything correctly before the drivers that need the hardware it sets up.
Verified to fix:
I suspect it will also fix the 2020 G15
502IU one user had issues with.
🔗 2020/2021 G14/G15 backlight
I touched on this last month. There's some work to be done that I haven't had a chance to get round to yet, so will do soon.
The basis is: the backlight control isn't correctly set up in the kernel and the current patch is causing a side-effect that makes it work.
I'm currently maintaining a git repo for fedora kernel to include the
pinctrl_amd module builtin, and all the patches for base ROG functions + for correctly suspend (verified on 2021 G14 so far).
These patches are all pulled from this git branch.
Confirmation of G15 is in progress. This post will be updated in the next day or so.
If you think I've missed anything important please ping me (on discord).