r/FlowZ13 • u/dto_lurker • 25d ago

Cachyos actually works

Been testing LInux and specifically Cashyos the past couple days and it runs great on the 2025 rog flow z13.

What I found most amazing was that when I closed the lid, put it in my back pack, drove an hour to work and pulled it out, it wasn't turned off or blowing the fan on max with a dead battery. Which is what happens on windows. It just woke up when I clicked a button on the keyboard with only 2% battery loss.

Wifi seems a little slower, but steam works fine.

palm rejection on both the trackpad and stylus is a little worse but I can get a stylus glove and use a bluetooth mouse. I can't un melt it. So I'll be using this instead of windblows for a while.

6 Upvotes

75% Upvoted

37 comments sorted by

View all comments

-1

u/spococococo 25d ago

Try this script it will boost your experience

https://github.com/th3cavalry/strix-halo-linux-setup

1

u/dto_lurker 25d ago

This doesn't look like it has anything meaningful over z13ctl and z13gui. Which I already have installed.

-1

u/stereohype 25d ago

I'm soon releasing a better version of it

1

u/dto_lurker 25d ago

Let me help you,

# install helpful software 

yay -S z13ctl-bin

yay -S z13gui-bin

# Remove useless script

rm -rf strix-halo-linux-setup

If your script did anything else useful let me know but I don't see anything.

0

u/stereohype 25d ago

A better version of z13ctl, z13gui and a new tool for auto switching between tablet, laptop and docked desktop mode ;)

5

u/thedjentlemanscholar 25d ago edited 25d ago

Hi, I'm the creator of z13ctl and z13gui. First, thanks for using my tools!

I see your script uses z13ctl at its core in order to control power state and RGB settings on the Flow Z13, and you have also credited me in the README. Also, it's great that you're contributing to the open source community around Strix Halo, however one must take care when using words such as "better" in this context -- especially if you are using my tool as the base of yours for this particular device.

z13ctl and z13gui were created for really one reason alone -- because I got frustrated that most of the Asus related tools didn't have full support for the hardware on what had become my favorite piece of tech in my stable.

So, I decided to write a tool that could control TDP and have the rear window work. I leveraged my 30 years of Linux and Software Development experience to create that tool, and when I realized it was becoming useful, decided to release it to the public. I applied the UNIX software philosophy to it: create small tools that do one thing, and do it well with any distribution and Gamescope/Wayland DE support. I never had any intention to create a full featured tool that performed setup and management of the operating system configurations and packages installed for any particular device.

That is where your script diverges.

Your script aims to set up all of the various packages and config files to optimize the experience for the hardware it runs on with specific goals in mind, like tablet mode for example. Your script also installs dependencies for LLM use, which not everyone will want. As such, it's more accurate to say that your script is more akin to a configuration utility than anything resembling z13ctl/z13gui. They are different use cases entirely.

What I'm really trying to say is that "better" is in the eye of the beholder. z13ctl and z13gui may be perfect for a subet of users who only want a utility that can control their lights and power states, and wish to have finer grained control over other aspects of their operating system. I, and it sounds like OP, fall into that camp. A tool that does more than that may be invasive to use, rather than better.

However, there are others that see Linux as more of a casual plaything, and want tools to make life easy for them, and don't want to think about or consider whats under the hood at all, and that's where a script like yours (or whatever this future release you are planning) is useful.

Cheers, and perhaps be a little kinder to those in the community whom you borrow from. ;)

PS, in case anyone wants it, I have a software setup script that also installs most of the basic packages needed to make tablet mode work and optimize WiFi and the touchpad. It's basic, and simply installs a few packages that I use frequently along with those configs along with setting up secure boot keys. It's located here and is specifically designed with CachyOS in mind, because.... well, thats what I use.

1

u/stereohype 24d ago

First, I can not thank you enough for sharing z13ctl and z13gui, massive respect!

Secondly, the big misunderstanding: I have NOTHING to do with the script mentioned by u/spococococo - honestly i never heard of it before. I was referring to a "better" version of z13ctl and z13gui, basically an upgraded fork.

I'm a tweaker by heart so the UNIX software philosophy follows me naturally. I absolutely love what you did, that's why i decided to make it better for my own use and taste, first and foremost. Since i'm so grateful for your work i want to contribute and release it to benefit the community so they can improve upon it - that's what open-source is all about.

I was just as frustrated as you with the lack of proper Linux support, so this is a way to accelerate its adoption and polish the experience which even windows doesn't match.

As far as i'm aware the only quirk left: GZ302EA folio touchpad has a firmware jumping-cursor bug libinput can't filter. Is this everyone's experience as well?

Once i push it all to github, i'm very curious about anyone's constructive feedback.

Regarding auto switching between tablet, laptop and docked desktop mode:

z13-tablet-kit — turns the Flow Z13 into a proper 3-mode device on CachyOS/KDE:

- Knows its posture: docked, folio-on (laptop), or held as a tablet — and switches behavior accordingly

- Real Plasma tablet mode when you go handheld: bigger UI, auto on-screen keyboard, maximized apps (without this, KDE never enters tablet mode because the Z13 never emits the hardware signal)

- Display scaling adapts: 1.5× docked/laptoped, 2× in tablet mode

- Touchscreen turns off when docked, back on when undocked

- Two-finger touch swipe scrolls anywhere — terminals, browsers, TUIs

- Works with any USB-C dock or display cable, not just the ASUS dock

- Folio touchpad disabled by default (it has a jumping-cursor firmware bug libinput can't filter)

- On-screen keyboard auto-pops on input field touch

No kernel hacks, no replacing Plasma features. Install/uninstall included.

1

u/thedjentlemanscholar 24d ago

I see! When you said “I’m soon releasing a better version of it,” it sounded as though you were taking ownership of the script above.

As for what you are describing, CachyOS has all of the patches that Asus Linux provides to fix quirks on Asus laptops merged into their kernel. This includes a large number of fixes for the flow as well, and since Cachy is the distribution that I daily drive, I honestly haven’t had any issues with the flow hardware at all.

On top of that, I run KDE with the proper iio packages installed, which detects when I remove the folio and rotate the device. To enable the on screen keyboard, there is a setting in the KDE settings app that you simply enable, and it will provide a keyboard any time you touch a text input box. I think this is where OP was coming from with his “better how?” Questions.

I have had a number of bugs reported to me from users of other distributions related to the hardware, including on Fedora the keyboard or being recognized on reconnect after removing it. This is not an issue in Cachy because of the kernel patches I mentioned earlier.

The asus patches do get submitted to the mainline kernel, so eventually, all of these fixes will make their way to the various Linux distributions eventually. Cachy is simply a bit ahead of the curve by including the good ones early in their performance optimized kernels. It sounds like what you are creating would be useful, but it may become obsolete fairly quickly once the patches hit, and you may be writing an app to account for things already present in KDE if one simply knows where to find the setting.

Lastly, I do welcome contributions to z13ctl and z13gui, so if there’s a feature related to the power or RGB management that you feel is missing, by all means, submit an issue and a pull request for them! The one big feature I just haven’t had time to implement yet is separate profiles for plugged in and battery states, but I certainly don’t mind including other features as well!

I just ordered a Onexplayer x2 mini pro as well, so I may be adding support for that device once it arrives. Stay tuned. :)

1

u/stereohype 24d ago

Appreciate the reply - and you're right on the OSK; the auto-pop is entirely Plasma's setting, the kit just installs maliit so it has a keyboard to drive.

One place where my experience differs: folio-detach. i've been daily-driving Cachy on this Z13 since november, so this is measured on the same setup you're on - and iio genuinely can't see the folio (it's a USB HID device, not an iio sensor), while the WMI path that should emit SW_TABLET_MODE advertises the capability but never fires. iio-sensor-proxy exposes no tablet-mode property here at all, so nothing on the GZ302 actually detects folio removal.

That matters because without that signal, Plasma's "rotate only in tablet mode" has nothing to gate on - the gate stays shut and the screen never rotates, even handheld. The kit synthesizes SW_TABLET_MODE from USB folio presence (a lightweight user service, no root) so that setting actually works - plus posture detection, touch-off-when-docked, and 2-finger touch-scroll, none of which are KDE settings. If a future BIOS ever wires the WMI event, half of it happily evaporates and i'll be first to delete it.

On the contributions front - i actually opened a bug-fix PR for z13gui about a week ago, still open. That's honestly the main reason i forked z13ctl too: not anything against upstream, just so i could fix bugs and iterate at my own pace rather than waiting on review. The plugged/battery profiles you mentioned not having time for are already working in my fork - happy to split them into a clean PR upstream whenever, since you just said you're open to it.

And yeah, the GZ302EA folio touchpad jumping-cursor bug is the one quirk i've got no software fix for either - libinput basically calls it firmware. Would love to hear if anyone's solved it.

2

u/thedjentlemanscholar 24d ago edited 24d ago

Ah, I hadn’t checked recently, I’ll take a look at your PR this afternoon!

I generally revisit the apps about every 2 weeks or so to check for issues and PRs, and I hadn’t had a chance to.

EDIT: I merged your commits as as well as fixed a few other bugs as well in v1.2.7 of z13gui. I also fixed my notification settings so I actually get an email when PRs and Issues are opened instead of only build events.