THectic-NL · Stensel8 · Sep 14, 2026 · Sep 14, 2026 · Sep 14, 2026 · Sep 14, 2026
@@ -12,10 +12,14 @@ The Zephyrus G16 has a lot of hardware features that don't work out of the box o
 {{< /callout >}}
 
 **Package Information (at the time of writing):**
-- `asusctl` 6.4.0: CLI frontend for fan curves, profiles, battery limit, RGB, Slash LED, GPU switching. Also ships `asusd`, the background daemon that actually talks to the hardware, and its systemd service. There's no separate `asusd` package to install: `pacman -Q asusd` / `rpm -q asusd` will come back empty even though the daemon is very much there.
-- `rog-control-center` 6.4.0: graphical frontend, communicates with asusd
+- `asusctl` 6.5.0: CLI frontend for fan curves, profiles, battery limit, RGB, Slash LED, GPU switching. Also ships `asusd`, the background daemon that actually talks to the hardware, and its systemd service. There's no separate `asusd` package to install: `pacman -Q asusd` / `rpm -q asusd` will come back empty even though the daemon is very much there.
+- `rog-control-center` 6.5.0: graphical frontend, communicates with asusd
 - Source: [asusctl releases](https://github.com/OpenGamingCollective/asusctl/releases) · in the CachyOS/Arch repos, and in [Terra](https://terra.fyralabs.com/) for Fedora
 
+{{< callout type="info" >}}
+**6.5.0** ([release notes](https://github.com/OpenGamingCollective/asusctl/releases/tag/6.5.0), tagged September 13, 2026) is mostly a stability and validation pass: a fix for MUX writes failing in certain cases, better fan-curve and firmware-attribute write validation, GPU wake-up by telemetry fixed, fan curves now update after a profile change, and new Aura lighting support for several other Strix models. That MUX-write fix lines up with the batch-write bug tracked in [Known Issues]({{< relref "/docs/known-issues" >}}) (`asusctl#318`): its two upstream commits landed in late August, before this tag, so 6.5.0 is the first tagged release that should carry it. Confirm with `asusctl info` once your distro packages the update.
+{{< /callout >}}
+
 {{< callout type="info" >}}
 Verify what's actually installed with `asusctl info` (prints the asusctl version alongside detected hardware) or `pacman -Q asusctl rog-control-center` / `rpm -q asusctl rog-control-center`.
 {{< /callout >}}
@@ -440,6 +444,12 @@ Kernel 7.0 shipped in April 2026 and CachyOS picked it up fast. For this ASUS RO
 
 **Sources:** [Linus confirms Linux 7.0](https://www.phoronix.com/news/Linux-7.0-Is-Next) · [HID laptop quirks for ASUS ROG models](https://www.phoronix.com/news/Linux-7.0-HID) · [Linux 7.0 DRM/AMDGPU updates](https://www.phoronix.com/news/Linux-7.0-Graphics-Drivers)
 
+### Linux 7.3: scheduler rework and storage/memory wins (not out yet)
+
+Not released yet, but close. `7.3-rc1` landed August 30, 2026 and `rc3` on September 13, one rc every Sunday since; going by Linus's usual pattern of releasing about a week after rc7, that puts the final release around October 18, 2026 (October 25 if an extra rc8 turns out to be needed). Worth planning for: a scheduler rework that's measured up to 25% better average FPS on older/low-power hardware, with improved cluster-aware scheduling across core types. That's directly relevant here, not just an Intel P/E-core story: the Ryzen AI 9 HX 370 in this laptop is itself a mixed Zen5/Zen5c-core design. Alongside the scheduler work: Direct I/O now runs through an iomap bounce buffer instead of falling back to buffered I/O (roughly half of theoretical throughput up to close to 95%), Btrfs skips slow paths on Direct I/O and `fsync()`, a KSM reverse-mapping lock fix drops a worst-case stall from ~700ms to under 2ms, and `zsmalloc` sees less lock contention when several processes free compressed memory at once.
+
+**Sources:** [Phoronix: Linux 7.3 features overview](https://www.phoronix.com/review/linux-73-features) · [Phoronix: Linux 7.3 "flattens the pick" (scheduler)](https://www.phoronix.com/news/Linux-7.3-Flattens-The-Pick) · [9to5Linux: Linux 7.3-rc1 announced](https://9to5linux.com/linus-torvalds-announces-first-linux-kernel-7-3-release-candidate)
+
 
 ## Additional Resources
 

@@ -12,10 +12,14 @@ De Zephyrus G16 heeft veel hardware-functies die op Linux niet zomaar werken: fa
 {{< /callout >}}
 
 **Pakketinformatie (op het moment van schrijven):**
-- `asusctl` 6.4.0: CLI frontend voor fan curves, profielen, batterijlimiet, RGB, Slash LED, GPU-switching. Levert ook `asusd` mee, het achtergrondproces dat daadwerkelijk met de hardware praat, plus de bijbehorende systemd-service. Er is geen los `asusd`-pakket om te installeren: `pacman -Q asusd` / `rpm -q asusd` komt leeg terug terwijl de daemon er wel degelijk is.
-- `rog-control-center` 6.4.0: grafische frontend, communiceert met asusd
+- `asusctl` 6.5.0: CLI frontend voor fan curves, profielen, batterijlimiet, RGB, Slash LED, GPU-switching. Levert ook `asusd` mee, het achtergrondproces dat daadwerkelijk met de hardware praat, plus de bijbehorende systemd-service. Er is geen los `asusd`-pakket om te installeren: `pacman -Q asusd` / `rpm -q asusd` komt leeg terug terwijl de daemon er wel degelijk is.
+- `rog-control-center` 6.5.0: grafische frontend, communiceert met asusd
 - Bron: [asusctl releases](https://github.com/OpenGamingCollective/asusctl/releases) · in de CachyOS/Arch-repos, en in [Terra](https://terra.fyralabs.com/) voor Fedora
 
+{{< callout type="info" >}}
+**6.5.0** ([release notes](https://github.com/OpenGamingCollective/asusctl/releases/tag/6.5.0), getagd op 13 september 2026) is vooral een stabiliteits- en validatieronde: een fix voor MUX-writes die in bepaalde gevallen faalden, betere validatie bij het wegschrijven van fan curves en firmware-attributen, GPU-wake-up via telemetrie gefixt, fan curves worden nu na een profielwissel bijgewerkt, en nieuwe Aura-verlichtingsondersteuning voor een aantal andere Strix-modellen. Die MUX-write-fix komt overeen met de batch-write-bug uit [Known Issues]({{< relref "/docs/known-issues" >}}) (`asusctl#318`): de twee upstream-commits daarvoor landden eind augustus, vóór deze tag, dus 6.5.0 is de eerste getagde release die 'm zou moeten bevatten. Check met `asusctl info` zodra jouw distro de update pakketteert.
+{{< /callout >}}
+
 {{< callout type="info" >}}
 Controleer wat er daadwerkelijk geïnstalleerd is met `asusctl info` (toont de asusctl-versie samen met gedetecteerde hardware) of `pacman -Q asusctl rog-control-center` / `rpm -q asusctl rog-control-center`.
 {{< /callout >}}
@@ -440,6 +444,12 @@ Kernel 7.0 is in april 2026 uitgebracht en CachyOS pakte het snel op. Voor deze
 
 **Bronnen:** [Linus bevestigt Linux 7.0](https://www.phoronix.com/news/Linux-7.0-Is-Next) · [HID laptop quirks voor ASUS ROG modellen](https://www.phoronix.com/news/Linux-7.0-HID) · [Linux 7.0 DRM/AMDGPU updates](https://www.phoronix.com/news/Linux-7.0-Graphics-Drivers)
 
+### Linux 7.3: scheduler-herziening en storage/memory-winst (nog niet uit)
+
+Nog niet uitgebracht, maar dichtbij. `7.3-rc1` landde op 30 augustus 2026, `rc3` op 13 september, sindsdien elke zondag een nieuwe rc; volgens Linus' gebruikelijke patroon van ongeveer een week na rc7 komt de finale release rond 18 oktober 2026 uit (25 oktober als er alsnog een rc8 nodig blijkt). Interessant om op te letten: een scheduler-herziening die tot 25% betere gemiddelde FPS meet op oudere/low-power hardware, met verbeterde cluster-aware scheduling over verschillende coretypes heen. Dat is hier direct relevant, niet alleen een Intel P/E-core-verhaal: de Ryzen AI 9 HX 370 in deze laptop is zelf een gemengd Zen5/Zen5c-core-ontwerp. Naast het scheduler-werk: Direct I/O loopt nu via een iomap-bouncebuffer in plaats van terug te vallen op buffered I/O (van ruwweg de helft van de theoretische doorvoer naar bijna 95%), Btrfs slaat trage paden over bij Direct I/O en `fsync()`, een fix in KSM's reverse-mapping-lock brengt een worst-case stall terug van ~700ms naar onder de 2ms, en `zsmalloc` heeft minder lock-contentie als meerdere processen tegelijk gecomprimeerd geheugen vrijgeven.
+
+**Bronnen:** [Phoronix: Linux 7.3-overzicht](https://www.phoronix.com/review/linux-73-features) · [Phoronix: Linux 7.3 "flattens the pick" (scheduler)](https://www.phoronix.com/news/Linux-7.3-Flattens-The-Pick) · [9to5Linux: Linux 7.3-rc1 aangekondigd](https://9to5linux.com/linus-torvalds-announces-first-linux-kernel-7-3-release-candidate)
+
 
 ## Aanvullende Bronnen
 

@@ -59,7 +59,7 @@ Screen brightness control doesn't respond when only the AMD Radeon 890M iGPU is
 
 **Root cause (confirmed upstream):** this is [asusctl#318](https://github.com/OpenGamingCollective/asusctl/issues/318). GPU-mode changes are written in a batch when the system shuts down. A harmless no-op write in that same batch (re-writing a value that's already set) makes the ASUS WMI firmware return an I/O error, and the way that error is handled aborts the *entire* batch, including the write that would have actually switched the mode. So a mode switch can silently fail to apply at all, and brightness can end up broken as a side effect of the half-applied state. A closely related fix landed the very next day, reordering the coupled writes so `gpu_mux_mode` and `dgpu_disable` apply in the right sequence relative to each other.
 
-Fixed upstream: commit `940dba87` ("Fixes #318", merged 2026-08-21) and the ordering fix, commit `e0abda4b` (merged 2026-08-22). Both landed six to seven days **after** the current `6.4.0` tag (2026-08-15), and no newer tag has been cut since. So neither fix is in any tagged release yet. Whether a given install has them depends on whether the distro's package was built from a `main` snapshot newer than 2026-08-22, not from the `6.4.0` tag itself, regardless of what version string it reports.
+Fixed upstream: commit `940dba87` ("Fixes #318", merged 2026-08-21) and the ordering fix, commit `e0abda4b` (merged 2026-08-22). Both landed after the `6.4.0` tag (2026-08-15), which shipped without either fix. `asusctl` [6.5.0](https://github.com/OpenGamingCollective/asusctl/releases/tag/6.5.0) (tagged 2026-09-13) is the first tag cut since, and its changelog lists "Fix issue where MUX writes fail in certain cases," which lines up with this bug. Whether a given install has it depends on whether the distro's package has caught up to `6.5.0` yet. Unlike the `6.4.0` snapshot ambiguity above, `6.5.0` is a clean tag, so `asusctl info` reporting `6.5.0` is a reliable signal the fix is in. If the mode-switch symptoms below still show up on a confirmed `6.5.0` install, that's worth reporting upstream.
 
 **Ruled out by direct testing on this hardware, in order:**
 - Kernel parameters `nvidia.NVreg_EnableBacklightHandler=0` and `nvidia.NVreg_RegistryDwords=EnableBrightnessControl=0`. No effect.

@@ -59,7 +59,7 @@ Schermhelderheid reageert nergens op zolang alleen de AMD Radeon 890M iGPU actie
 
 **Oorzaak (bevestigd upstream):** dit is [asusctl#318](https://github.com/OpenGamingCollective/asusctl/issues/318). GPU-modewijzigingen worden in een batch weggeschreven bij het afsluiten van het systeem. Een onschuldige no-op write in diezelfde batch (een waarde herschrijven die al zo staat) laat de ASUS WMI-firmware een I/O-fout teruggeven, en door hoe die fout wordt afgehandeld breekt dat de **hele** batch af, inclusief de write die de mode daadwerkelijk had moeten wisselen. Een modewissel kan dus stilletjes helemaal niet toegepast worden, en de helderheid kan als bijeffect van die half-toegepaste staat kapot achterblijven. Een sterk gerelateerde fix landde de dag erna, die de gekoppelde writes herordent zodat `gpu_mux_mode` en `dgpu_disable` in de juiste volgorde ten opzichte van elkaar worden toegepast.
 
-Gefixt upstream: commit `940dba87` ("Fixes #318", gemerged 2026-08-21) en de ordening-fix, commit `e0abda4b` (gemerged 2026-08-22). Beide landden zes à zeven dagen **na** de huidige `6.4.0`-tag (2026-08-15), en er is sindsdien geen nieuwe tag uitgebracht. Geen van beide fixes zit dus in een getagde release. Of een installatie ze heeft hangt af van of het distro-pakket vanaf een `main`-snapshot nieuwer dan 2026-08-22 is gebouwd, niet vanaf de `6.4.0`-tag zelf, ongeacht welk versienummer het rapporteert.
+Gefixt upstream: commit `940dba87` ("Fixes #318", gemerged 2026-08-21) en de ordening-fix, commit `e0abda4b` (gemerged 2026-08-22). Beide landden na de `6.4.0`-tag (2026-08-15), die zonder beide fixes uitkwam. `asusctl` [6.5.0](https://github.com/OpenGamingCollective/asusctl/releases/tag/6.5.0) (getagd op 2026-09-13) is de eerste tag sindsdien, en de changelog noemt "Fix issue where MUX writes fail in certain cases", wat overeenkomt met deze bug. Of een installatie 'm heeft hangt af van of het distro-pakket al is bijgewerkt naar `6.5.0`. In tegenstelling tot de ambiguïteit rond `6.4.0` hierboven is `6.5.0` een schone tag, dus `asusctl info` dat `6.5.0` rapporteert is een betrouwbaar signaal dat de fix erin zit. Blijven de mode-switch-symptomen hieronder optreden op een bevestigde `6.5.0`-installatie, dan is dat het melden upstream waard.
 
 **Uitgesloten door direct testen op deze hardware, in volgorde:**
 - Kernelparameters `nvidia.NVreg_EnableBacklightHandler=0` en `nvidia.NVreg_RegistryDwords=EnableBrightnessControl=0`. Geen effect.

@@ -15,6 +15,10 @@ This is a script that applies three fixes at once (NetworkManager power saving,
 Test conditions, since they affect the numbers: a UniFi U7 Pro access point, in a wooden cabinet, roughly 10 meters from the laptop with a wall in between. 6GHz band, 160MHz channel (this card's max), signal ranging -62 to -71 dBm across runs, mostly -63 to -66 dBm. That's a realistic everyday distance, not a best-case same-room test, so treat the numbers above as a reasonable baseline rather than a ceiling.
 {{< /callout >}}
 
+{{< callout type="warning" >}}
+**Is this still worth doing?** Yes, for now -- every fix below has a measured, reproducible effect and costs nothing but a reboot. But don't mistake it for having fixed the card. These are workarounds for driver defaults that shouldn't have needed tuning in the first place, not a rewrite of what the silicon can do. Set against a two-year-old phone's Wi-Fi chip (see [Results](#results) below), the honest summary is that the MT7925 itself is a mediocre Wi-Fi 7 part, and no amount of tuning changes that. The upside: this isn't a dead end. MediaTek's Wi-Fi 7 stack is still under active upstream development, with patches landing as recently as this page's own testing window -- see [References](#references) below. If you'd rather wait for the driver to mature than tune it by hand, that's a reasonable call too.
+{{< /callout >}}
+
 ## Setup
 
 {{% steps %}}
@@ -151,6 +155,8 @@ The chip is still actively worked on; patches landed as recently as this week du
 - [ratatoskr.run](https://ratatoskr.run/): a more readable web archive of the same mailing lists.
 - [github.com/openwrt/mt76](https://github.com/openwrt/mt76): mirror of the driver source, easier to browse than the kernel.org tree.
 
+Recent proof that this is moving, not stalled: a [patch skipping scans during suspend](https://ratatoskr.run/linux-mediatek/2026/04/3520789) landed in April 2026 to stop command timeouts on resume, and an [mt7925 firmware update](https://ratatoskr.run/linux-wireless/2026/08/17426467/t) went out in August 2026. Neither is life-changing on its own, but the cadence is the point: this chip's driver and firmware get touched most months, not once a year.
+
 {{% /details %}}
 
 ## References
@@ -160,3 +166,5 @@ The chip is still actively worked on; patches landed as recently as this week du
 - [wifi: mt76: mt7925: disable ASPM for MT7927 to fix throughput collapse](https://lkml.iu.edu/hypermail/linux/kernel/2603.0/12526.html): upstream work on the same ASPM issue for the newer MT7927.
 - [MT7927 WiFi on Linux: Making It Work](https://jetm.github.io/blog/posts/mt7927-wifi-making-it-work/): the community reverse-engineering effort behind MT7927 support.
 - [Known Issues, Linux MT7921/MT7925 WiFi Driver Fixes](https://zbowling.github.io/mt7925/issues/known-issues/): a running list of chip-level issues and their status.
+- [From "Replace It with Intel" to Upstream: Bringing MediaTek Bluetooth/WiFi 7 to Linux](https://www.linaro.org/blog/from-replace-it-with-intel-to-upstream-bringing-mediatek-bluetooth-wifi-7-to-linux/): Linaro's account of how MediaTek's Wi-Fi 7 support went from an "unsupportable, replace the card" state to actively upstreamed, useful context for why this chip's situation looks better a year from now than it does today.
+- [MT7925 WiFi Driver Fixes, now packaged as DKMS](https://community.frame.work/t/mt7925-wifi-driver-fixes-now-available-as-dkms-package/79777): a community fix set for this chip, now installable as a DKMS module instead of hand-patching -- a sign fixes for this chip are stabilizing enough to package for end users.