Flow Z13 Asus Setup on Linux (May 2025) [WIP]

Wikis & How-to Guides
1

Wifi

AMD has to do better here. This is a mediatek 7925e and its been a bit of a pain to work the quirks out.

ASPM

On the flow it seems to work better if you create /etc/modprobe.d/mt7925e_wifi.conf and put in it
options mt7925e disable_aspm=1

Even with this it would still routinely only associate once per modprobe of the module. If you had a memorized network, NetworkManager would try to auto-join this network. Aborting this and trying to connect to any other network puts the module/card in a state where it will no longer work.

rmmod mt7925e; modprobe mt7925e would put it in a state where it would join again.

Interestingly this also seems related to the slowdown bug everyone experiences. When one of the radios stops it just stops … but removing and inserting the module works!

Firmware

You’re in for a bad time unless your linux-firmware is from 3/10/25 at the earliest. I strongly suspect more firmware fixes are inbound as this wifi module is a bit sus even on windows with these types of edge cases.

Suspend Resume quirks

Kernel 6.14.0-15-generic. Sometimes it just doesn’t come back from closing the keyboard folio. Sometimes.

Garbled Window for 1-frame

Gnome seems to do this thing where it displays a frame before the buffer has been filled. So you get RGB snow where the display is about to update. This seems to happen when the display isn’t running at 60hz. It seems to be AMDGPU + firmware related. I have been able to create specific situations to cause this problem, and work around it, but I haven’t nailed down a root cause. I remember gnome is (used to be?) juggling 3 frames at once. Not sure if that’s related.

Fixing the Flow Z13 Tohuchpad Detection on boot

The touchpad is not always detected as a touchpad. This is also a problem with CachyOS as well as ubuntu.

First if you create

# etc/modprobe.d/hid_asus.conf
# should contain 
options hid_asus enable_touchpad=1

then if you rmmod hid_asus && modprobe hid_asus the two finger touchopad will work. Frustratingly even if you update your initial ramdisk, and verify the module config is there, it doesn’t apply.

The reason is that udev + systemd load the modules and ignore module configuration because of course, systemd (the meme).

So here’s a workaround. We’ll make a little systemd server that runs once on boot to remove and reinsert the hid_asus module. A sort of systemd ouroboros if you will.

sudo nano /etc/systemd/system/reload-hid_asus.service

[Unit]
Description=Reload hid_asus with correct options
After=multi-user.target
ConditionKernelModule=hid_asus

[Service]
Type=oneshot
ExecStart=/usr/bin/modprobe -r hid_asus
ExecStart=/usr/bin/modprobe hid_asus

[Install]
WantedBy=multi-user.target

sudo systemctl enable reload-hid_asus.service

—

*Be aware that if you comment on this thread with tip sand tricks, I will probably lock the thread after the video goes live as the above post will evolve A LOT based on your comments and my own fumbling to make the Flow Z13 + AMD suck less natively on Linux. Well to be fair is is a breathtaking experience with steam games, bazzite, performance, 16 cores. Just some rough edges I am compelled to unrough *

5 Likes
4

Yes there is funny business with the mediatek 7925e, i have one in my zenbook s16 with the amd hx 370. I’m running arch linux and the current rolling release seems to have fixed most all the issues on my exact setup(arch is on 6.14.2), i know most of the bugfixes for the hx370 and the mediatek 7925e were planed to be merged into 6.14, and that seems to hold true for me at least.

See https://wiki.archlinux.org/title/ASUS_Zenbook_UM5606and the section 4.3 on wake from suspend related to the mediatek 7925. I no longer have to do this trick but pre 6.14 and current firmware i did.

I also had graphical issues in the past with previous kernels see Help with troubleshooting freezing with linux kernel 6.12 on arch but since 6.14 i have seen no issues for my hardware.

P.S. im aware the flow-z13 does not have a hx370

1 Like
5

I’m on bazzite right now I’m actually experiencing the same thing with KDE. It consistently shows up during boot for me and randomly occurs while I’m on desktop. Thinking it actually might be a general bazzite or universal blue bug.

I’m on a180Hz OLED monitor with a 7900XTX for my GPU… It doesn’t occur when I switch to the iGPU(Core i5 13600k). Haven’t had a whole lot of time to troubleshoot it myself, but it hasn’t occurred while I’m playing games so just a minor annoyance at the moment.

6

I thought i would add clarify i was also having rgb snow issues, i mainly use hyprland but also have gnome as backup. I can tell you it happened in both. I could make it go away(temporarily) by logging out and in, restarting hyprland or gnome. Also shuold note i used wayland for both. interestingly when arch updated to 6.14 i was still having it. Then i did a clean reinstall of arch and i have not had it since.

7

Hi I have experienced the same issues , tried cachyos bazzite nobara and fedora 42 as well as rawhide.
All KDE and same graphics problems, cachy I had to patch to get touch pad and lights to work with antheus patches.
Also cirrus has not to my knowledge up streamed the proper firmware for the sound.
I deleted everything is the cirrus folder at /usr/lib/firmware and copyed 5 files , sound is noticable better (bazzite will already have this) however sound still glitches sometimes while gaming with crackling and buzzing.

8

interesting. I’ve been running 25.04 but with mainline 6.14.6 kernel and kde on the desktop with Linux firmware from git and most of those issues are resolved. literally just got that working the last week though

9

I will try that I am on cachyos

10

I’ve been running Arch on the Z13 2025 (390 version - not the 395+) and its been generally pleasant, with a few observations:

  • Garbled/corrupted media playback at times (fixes by changing video resolution)
  • No way to change tdp (that i know of) atleast without handheld daemon. Kind of an issue on desktop mode since I use Niri.
  • Trackpad etc works with a patched kernel (I’m currently using linux-bazzite)
  • Needed linux-firmware-git as well, but not too sure if its still needed
  • Wi-Fi speeds are atrocious, no matter what I try
  • Sleep/Suspend etc work just fine
  • Performance is solid on both the CPU and iGPU
  • USB 4 eGPUs seem to bne kind of funky, I get poor performance on my hacky oculink to usb 4 setup. Meanwhile the OneXGPU refuses to give video outputs (despite having everything else working!)
    I’m sure these will get fixed over time but honestly I’m pretty impressed at what this thing is caapble of, even with the lower specced version.
11

Just wondering here, because I suspected this, but could not confirm: is the memory really “unified” or is it shared?

Unified would be more like on the M-series Macs where the OS can ad-hoc assign memory to the GPU and CPU as needed.

Shared would be more like the “olden days” where the OS/BIOS partitions memory in more-or-less fixed buckets.

The reason why I ask is based on a comment from Alex Ziskind in this video: https://www.youtube.com/watch?v=AcTmeGpzhBk

The fact that there are BIOS settings (or crate settings) that can partition the memory and requires a reboot makes me think that Strix Halo isn’t as flexible as what M-Series Macs are doing.

Or I can be completely confused about both. … but I don’t think I am. :wink:

12

so you can still partition for old software compatibility but there is also a path now for software that is newer and smarter to access system memory directly without the extra copy.

so it’s a sort of weird in-between state. also there was a bug that prevented unified access above a 64gh boundary but I think? that’s been fixed

13

So, does that mean that the BIOS/Amory Crate settings are just there to “emulate” a traditional GPU with GPU memory and “system memory,” but the “auto” setting is really something resembling “unified?”

What software understands this? Does AMD’s implementation of OpenGL/CL and Vulkan “go through the motions” of sending/receiving data to/from the GPU, but keeps things in place because both the CPU and GPU can just access the same memory? My understanding is that Apple’s approach via Metal does this. Perhaps I’m confused.

14

Auto is, I think, a smallish amount like 2gb for legacy software compatibility. Auto is not special or “more unified”.

It might be worth looking at the DX12 documentation for UMA optimizations as it explains how to use the api primitives and is pretty well documented.

Upload Heap (D3D12_HEAP_TYPE_UPLOAD): (cpu writable, gpu readable allocation)
Readback Heap (D3D12_HEAP_TYPE_READBACK):
(cpu readable gpu writable)

Note you can also do custom access as well i.e. D3D12_RESOURCE_FLAG_ALLOW_SIMULTANEOUS_ACCESS but this is really getting into the weeds. There are a lot of landmines here like 4k alignment concerns and some other gotchas I dont recall off the top of my head.

Similar stuff is in vulkan but it takes a bit longer to grok imho.

D3D12_HEAP_PROPERTIES heapProps = {};
heapProps.Type = D3D12_HEAP_TYPE_UPLOAD;

device->CreateCommittedResource(
    &heapProps,
    D3D12_HEAP_FLAG_NONE,
    &resourceDesc,
    D3D12_RESOURCE_STATE_GENERIC_READ,
    nullptr,
    IID_PPV_ARGS(&resource));

vs

VkMemoryAllocateInfo allocInfo = {};
allocInfo.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO;
allocInfo.memoryTypeIndex = findMemoryType(physicalDevice, memoryRequirements.memoryTypeBits, 
                            VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | 
                            VK_MEMORY_PROPERTY_HOST_COHERENT_BIT);

vkAllocateMemory(device, &allocInfo, nullptr, &textureMemory);

Its pretty easy to choose if you want the memory to be accessible to both the cpu and gpu, theres the literal host_visible_bit and thats what eliminates the need to copy from “cpu memory” to “gpu memory”

Theres a lot of overlap here with what AMD terms “smart access memory”

Obviously texture memory is the low hanging fruit here so there could be some merit to mapping more than 2gb (imho).

I also experienced bizzare behavior from the HP G1A which allocated just 512mb. Obviously HP was a lot more hopeful that UMA would be better utilized in software packages than reality. Imho 4gb is reasonable to give up and as a practical matter most modern games run fine in 4gb + UMA. What I’m saying is that even very modern games are often not optimized to use DX12/vulkan UMA as well as they should but imho the texture memory is the easiest thing to implement and so often is.

15

Adding in my observation. Hopefully they can help others. And maybe I can get some answers to.
I’m on Fedora 42, stock 6.4.19 kernel.

  • I have the WiFi issues everybody is talking about.
  • I don’t have issues with media playback
  • Trackpad works
  • I was previously on the cachyos-rog kernel (6.14.9 and 6.15). This caused issues with Wayland. A lot of apps would start up in X11 through XWayland and XWayland would frequently crash, causing windows to not render. Don’t know if this is the device or kernel. Switching to stock kernel solved this.
  • Keyboard backlight function key, stops working after a while. GUI controls still work. Reconnecting the keyboard or rebooting solves this.
  • Random “freezes” while on battery. Technically not freezes, everything just runs so slow, that it might as well be frozen. I’ve tracked this down to constant kernel interrupts, related to power save mode for some hardware. It’s really hard to debug, when the computer is barely responding. To resolve this, I press the power button an wait (not hold, just press). This will eventually turn off the screen and clear the interrupts from the kernel. The press again, log in and you’re back to normal.
16

One more thing.
It doesn’t work with this monitor. This is not a Linux issue. It doesn’t work in Windows either. Display and power work over USB-C, but no peripherals. If I use a cable, that doesn’t support display, I get the peripherals. All my other laptops work with this monitor and all my other monitors and KVMs work with the laptop. Neither Philips nor Asus support have been able to solve this.

17

Interesting. W.r.t. the Vulkan calls, SADLY I’m familiar with that insane boilerplate engine :rofl:

What I understand about the M-series Macs is that there is a dynamic/floating sharing of memory between the GPU and CPU. It’s not fixed, but capped (at 75% of system memory). Just like system memory is a virtual memory map the GPU memory is also virtual memory mapped (details in this video: Metal Compute on MacBook Pro - Tech Talks - Videos - Apple Developer). So, one moment memory XXXX-YYYY is used as “system memory,” a few moments later, it’s used by the GPU.

Referring to your examples above, yes, I would expect the memory region to be mapped so that when the appropriate lock is acquired, you can modify the memory, and after the release of the lock, the GPU can do “whatever.”

But it sounds like the memory is sharing system memory but “owned” by the GPU on Strix Halo, and that the various APIs allow one to write (without copy) into the memory window when locked. However, unlike the M-Series Macs, one cannot claim “GPU” memory as system memory (to be used as “normal memory”). So, memory does not dynamically float between GPU and CPU “ownership.” There is a red line beyond which first-class ownership is the GPU, and via graphics APIs, and acquiring locks, you can manipulate stuff across the line. Still, there isn’t a software way to say, “Mr. GPU, there is a total dynamic demand for only 2GB of GPU memory, and the CPU would like to take ownership of the rest.” It appears that macOS manages things this way.

Or I could be completely wrong.

18

Mr. Dave covers the “shared”/“unified” issue here: https://youtu.be/Cn_nKxl8KE4?si=DXcVI6OomTNN_3HS

TALK ABOUT TIMING!! :rofl:

Yes, it’s not quite the same as the AI 395+ Max, but it’s pretty close, and his description resonates with my understanding of the situation. Anywho…

19

Actually, the Ryzen machine (https://www.gmktec.com/products/amd-ryzen™-ai-max-395-evo-x2-ai-mini-pc) is a AI Max+ 395-based system … so TIL!

Anywho

20

For anyone interested in the “freeze” issue, it appears to be this one.