From bfd40ca5a0e0a8c94a5da6ba26addcbd021470fa Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 14 Sep 2026 13:50:55 +0000 Subject: [PATCH 1/3] docs: reframe MT7925 tuning as a stopgap, bump asusctl to 6.5.0, add Linux 7.3 preview - MT7925 page: add a callout up front that the tweaks are real but don't fix the underlying mediocre chip, and point at active upstream driver work (recent patches, MediaTek's Wi-Fi 7 upstreaming effort, packaged DKMS fixes) as the actual path forward. - asusctl: bump asusctl/rog-control-center references to 6.5.0, note its changelog highlights and that it's likely the first tag carrying the asusctl#318 MUX write fix. - known-issues: update the #318 fix status now that 6.5.0 has been tagged. - asusctl-rog-control: add a Kernel Updates entry previewing Linux 7.3's scheduler/storage/memory improvements and its expected October release. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01TZivc1KUNuWxetiyHiD6o5 --- src/content/docs/hardware/asusctl-rog-control.md | 14 ++++++++++++-- .../docs/hardware/asusctl-rog-control.nl.md | 14 ++++++++++++-- src/content/docs/known-issues.md | 2 +- src/content/docs/known-issues.nl.md | 2 +- .../docs/networking/mt7925-wifi-performance.md | 8 ++++++++ .../docs/networking/mt7925-wifi-performance.nl.md | 8 ++++++++ 6 files changed, 42 insertions(+), 6 deletions(-) diff --git a/src/content/docs/hardware/asusctl-rog-control.md b/src/content/docs/hardware/asusctl-rog-control.md index 246d600..41ed9c0 100644 --- a/src/content/docs/hardware/asusctl-rog-control.md +++ b/src/content/docs/hardware/asusctl-rog-control.md @@ -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: fixed MUX write failures in certain scenarios, 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. The "MUX write failures" 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; on the usual 9-10 week cycle 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 diff --git a/src/content/docs/hardware/asusctl-rog-control.nl.md b/src/content/docs/hardware/asusctl-rog-control.nl.md index 508b9f9..88fc089 100644 --- a/src/content/docs/hardware/asusctl-rog-control.nl.md +++ b/src/content/docs/hardware/asusctl-rog-control.nl.md @@ -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: MUX-schrijffouten in bepaalde scenario's gefixt, 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. De "MUX-schrijffouten"-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; bij de gebruikelijke cyclus van 9-10 weken 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 diff --git a/src/content/docs/known-issues.md b/src/content/docs/known-issues.md index 8eee49b..fadb6c2 100644 --- a/src/content/docs/known-issues.md +++ b/src/content/docs/known-issues.md @@ -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 "resolved MUX write failures in certain scenarios," 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, not on the version string alone, so verify against `asusctl info` and check for the mode-switch symptoms below before assuming it's fixed on your system. **Ruled out by direct testing on this hardware, in order:** - Kernel parameters `nvidia.NVreg_EnableBacklightHandler=0` and `nvidia.NVreg_RegistryDwords=EnableBrightnessControl=0`. No effect. diff --git a/src/content/docs/known-issues.nl.md b/src/content/docs/known-issues.nl.md index 9f9a0f9..87a9c28 100644 --- a/src/content/docs/known-issues.nl.md +++ b/src/content/docs/known-issues.nl.md @@ -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 "resolved MUX write failures in certain scenarios", wat overeenkomt met deze bug. Of een installatie 'm heeft hangt af van of het distro-pakket al is bijgewerkt naar `6.5.0`, niet alleen van het versienummer, dus check dit met `asusctl info` en let op de mode-switch-symptomen hieronder voordat je aanneemt dat het op jouw systeem is opgelost. **Uitgesloten door direct testen op deze hardware, in volgorde:** - Kernelparameters `nvidia.NVreg_EnableBacklightHandler=0` en `nvidia.NVreg_RegistryDwords=EnableBrightnessControl=0`. Geen effect. diff --git a/src/content/docs/networking/mt7925-wifi-performance.md b/src/content/docs/networking/mt7925-wifi-performance.md index 39d2050..b728ba9 100644 --- a/src/content/docs/networking/mt7925-wifi-performance.md +++ b/src/content/docs/networking/mt7925-wifi-performance.md @@ -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 [Where to follow active development](#where-to-follow-active-development) 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 driver gets 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): the community fix set from the "Where to follow active development" list above, now installable without hand-patching -- a sign the fixes are stabilizing enough to package. diff --git a/src/content/docs/networking/mt7925-wifi-performance.nl.md b/src/content/docs/networking/mt7925-wifi-performance.nl.md index 8e28960..8cb07a9 100644 --- a/src/content/docs/networking/mt7925-wifi-performance.nl.md +++ b/src/content/docs/networking/mt7925-wifi-performance.nl.md @@ -15,6 +15,10 @@ Dit is een script dat drie fixes tegelijk toepast (NetworkManager-powersave, PCI Testomstandigheden, want die beïnvloeden de cijfers: een UniFi U7 Pro access point, in een houten kast, ongeveer 10 meter van de laptop met een muur ertussen. 6GHz-band, 160MHz-kanaal (het maximum van deze kaart), signaal variërend van -62 tot -71 dBm over de runs, meestal -63 tot -66 dBm. Dat is een realistische alledaagse afstand, geen beste-geval-test in dezelfde kamer, dus zie de cijfers hierboven als een redelijke baseline en niet als plafond. {{< /callout >}} +{{< callout type="warning" >}} +**Is dit nog steeds de moeite waard?** Voorlopig wel -- elke fix hieronder heeft een gemeten, reproduceerbaar effect en kost niets behalve een herstart. Maar zie het niet aan voor "de kaart gefixt": dit zijn workarounds voor driver-defaults die nooit getuned hadden hoeven worden, geen herschrijving van wat de silicon kan. Afgezet tegen de wifi-chip van een telefoon van twee jaar oud (zie [Resultaten](#resultaten) hieronder) is de eerlijke conclusie dat de MT7925 zelf gewoon een middelmatige Wi-Fi 7-kaart is, en geen enkele tuning verandert dat. Het goede nieuws: dit is geen doodlopende weg. MediaTek's Wi-Fi 7-stack wordt nog steeds actief upstream ontwikkeld, met patches die nog deze testweek van deze pagina landden -- zie [Waar je actieve ontwikkeling volgt](#waar-je-actieve-ontwikkeling-volgt) hieronder. Liever wachten tot de driver volwassener is dan zelf tunen? Ook een prima keuze. +{{< /callout >}} + ## Installatie {{% steps %}} @@ -151,6 +155,8 @@ Er wordt nog steeds actief aan deze chip gewerkt; er landden patches nog deze we - [ratatoskr.run](https://ratatoskr.run/): een beter leesbaar webarchief van dezelfde mailinglists. - [github.com/openwrt/mt76](https://github.com/openwrt/mt76): spiegel van de driverbroncode, makkelijker te doorbladeren dan de kernel.org-tree. +Recent bewijs dat dit beweegt, niet stilstaat: een [patch die scans tijdens suspend overslaat](https://ratatoskr.run/linux-mediatek/2026/04/3520789) landde in april 2026 om command-timeouts bij resume te stoppen, en een [mt7925-firmware-update](https://ratatoskr.run/linux-wireless/2026/08/17426467/t) ging uit in augustus 2026. Geen van beide is op zichzelf spectaculair, maar het tempo is het punt: deze driver wordt de meeste maanden aangeraakt, niet één keer per jaar. + {{% /details %}} ## Meer lezen @@ -160,3 +166,5 @@ Er wordt nog steeds actief aan deze chip gewerkt; er landden patches nog deze we - [wifi: mt76: mt7925: disable ASPM for MT7927 to fix throughput collapse](https://lkml.iu.edu/hypermail/linux/kernel/2603.0/12526.html): upstream-werk aan hetzelfde ASPM-probleem voor de nieuwere MT7927. - [MT7927 WiFi on Linux: Making It Work](https://jetm.github.io/blog/posts/mt7927-wifi-making-it-work/): de community reverse-engineering-inspanning achter MT7927-support. - [Known Issues, Linux MT7921/MT7925 WiFi Driver Fixes](https://zbowling.github.io/mt7925/issues/known-issues/): een lopende lijst van chip-niveau issues en hun 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 verhaal over hoe MediaTek's Wi-Fi 7-support van "niet te ondersteunen, vervang de kaart" naar actief geüpstreamd ging -- nuttige context voor waarom de situatie van deze chip er over een jaar beter uitziet dan vandaag. +- [MT7925 WiFi Driver Fixes, nu als DKMS-package](https://community.frame.work/t/mt7925-wifi-driver-fixes-now-available-as-dkms-package/79777): de community-fixset uit de lijst "Waar je actieve ontwikkeling volgt" hierboven, nu installeerbaar zonder handmatig patchen -- een teken dat de fixes stabiel genoeg worden om te packagen. From 6356bf04afa5c1456a3244d9160026ae2ce9ab66 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 14 Sep 2026 14:02:39 +0000 Subject: [PATCH 2/3] fix: point MT7925 callout links at a real heading anchor The new callout linked to #where-to-follow-active-development and its NL equivalent, but that's a {{% details %}} shortcode title, not a Markdown heading, so Hugo never generates that anchor id. lychee's link check caught it. Point both links at the References/Meer lezen section instead, which are real headings the same build already resolves fine. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01TZivc1KUNuWxetiyHiD6o5 --- src/content/docs/networking/mt7925-wifi-performance.md | 2 +- src/content/docs/networking/mt7925-wifi-performance.nl.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/networking/mt7925-wifi-performance.md b/src/content/docs/networking/mt7925-wifi-performance.md index b728ba9..fa4b967 100644 --- a/src/content/docs/networking/mt7925-wifi-performance.md +++ b/src/content/docs/networking/mt7925-wifi-performance.md @@ -16,7 +16,7 @@ Test conditions, since they affect the numbers: a UniFi U7 Pro access point, in {{< /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 [Where to follow active development](#where-to-follow-active-development) below. If you'd rather wait for the driver to mature than tune it by hand, that's a reasonable call too. +**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 diff --git a/src/content/docs/networking/mt7925-wifi-performance.nl.md b/src/content/docs/networking/mt7925-wifi-performance.nl.md index 8cb07a9..842c638 100644 --- a/src/content/docs/networking/mt7925-wifi-performance.nl.md +++ b/src/content/docs/networking/mt7925-wifi-performance.nl.md @@ -16,7 +16,7 @@ Testomstandigheden, want die beïnvloeden de cijfers: een UniFi U7 Pro access po {{< /callout >}} {{< callout type="warning" >}} -**Is dit nog steeds de moeite waard?** Voorlopig wel -- elke fix hieronder heeft een gemeten, reproduceerbaar effect en kost niets behalve een herstart. Maar zie het niet aan voor "de kaart gefixt": dit zijn workarounds voor driver-defaults die nooit getuned hadden hoeven worden, geen herschrijving van wat de silicon kan. Afgezet tegen de wifi-chip van een telefoon van twee jaar oud (zie [Resultaten](#resultaten) hieronder) is de eerlijke conclusie dat de MT7925 zelf gewoon een middelmatige Wi-Fi 7-kaart is, en geen enkele tuning verandert dat. Het goede nieuws: dit is geen doodlopende weg. MediaTek's Wi-Fi 7-stack wordt nog steeds actief upstream ontwikkeld, met patches die nog deze testweek van deze pagina landden -- zie [Waar je actieve ontwikkeling volgt](#waar-je-actieve-ontwikkeling-volgt) hieronder. Liever wachten tot de driver volwassener is dan zelf tunen? Ook een prima keuze. +**Is dit nog steeds de moeite waard?** Voorlopig wel -- elke fix hieronder heeft een gemeten, reproduceerbaar effect en kost niets behalve een herstart. Maar zie het niet aan voor "de kaart gefixt": dit zijn workarounds voor driver-defaults die nooit getuned hadden hoeven worden, geen herschrijving van wat de silicon kan. Afgezet tegen de wifi-chip van een telefoon van twee jaar oud (zie [Resultaten](#resultaten) hieronder) is de eerlijke conclusie dat de MT7925 zelf gewoon een middelmatige Wi-Fi 7-kaart is, en geen enkele tuning verandert dat. Het goede nieuws: dit is geen doodlopende weg. MediaTek's Wi-Fi 7-stack wordt nog steeds actief upstream ontwikkeld, met patches die nog deze testweek van deze pagina landden -- zie [Meer lezen](#meer-lezen) hieronder. Liever wachten tot de driver volwassener is dan zelf tunen? Ook een prima keuze. {{< /callout >}} ## Installatie From 69091cf32dfacac115df4ec99c7f89d1d382d18c Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 14 Sep 2026 14:13:53 +0000 Subject: [PATCH 3/3] fix: address Copilot review findings on PR #157 - Fix Linux 7.3 release date reasoning: rc1 (Aug 30) to final (Oct 18) is ~7 weeks per the actual rc schedule, not the "9-10 week cycle" I'd quoted, which describes the full cycle including the merge window, not rc1-to-release. Reworded to derive the date from the actual weekly rc cadence instead. - Fix a misquoted asusctl 6.5.0 changelog line: the real text is "Fix issue where MUX writes fail in certain cases," not the paraphrase I'd put in quotes. - Fix circular verification logic in Known Issues: checking `asusctl info` for version 6.5.0 *is* reliable now that it's a clean tag, unlike the ambiguous 6.4.0 snapshot situation being described. - Fix a source misattribution: the DKMS-packaged MT7925 fix set isn't one of the three links in the "Where to follow active development" list, so stop implying it is. - Soften "this driver gets touched most months" since one of the two cited items is a firmware update, not a driver change. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01TZivc1KUNuWxetiyHiD6o5 --- src/content/docs/hardware/asusctl-rog-control.md | 4 ++-- src/content/docs/hardware/asusctl-rog-control.nl.md | 4 ++-- src/content/docs/known-issues.md | 2 +- src/content/docs/known-issues.nl.md | 2 +- src/content/docs/networking/mt7925-wifi-performance.md | 4 ++-- src/content/docs/networking/mt7925-wifi-performance.nl.md | 4 ++-- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/content/docs/hardware/asusctl-rog-control.md b/src/content/docs/hardware/asusctl-rog-control.md index 41ed9c0..a737742 100644 --- a/src/content/docs/hardware/asusctl-rog-control.md +++ b/src/content/docs/hardware/asusctl-rog-control.md @@ -17,7 +17,7 @@ The Zephyrus G16 has a lot of hardware features that don't work out of the box o - 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: fixed MUX write failures in certain scenarios, 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. The "MUX write failures" 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. +**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" >}} @@ -446,7 +446,7 @@ Kernel 7.0 shipped in April 2026 and CachyOS picked it up fast. For this ASUS RO ### 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; on the usual 9-10 week cycle 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. +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) diff --git a/src/content/docs/hardware/asusctl-rog-control.nl.md b/src/content/docs/hardware/asusctl-rog-control.nl.md index 88fc089..0374a15 100644 --- a/src/content/docs/hardware/asusctl-rog-control.nl.md +++ b/src/content/docs/hardware/asusctl-rog-control.nl.md @@ -17,7 +17,7 @@ De Zephyrus G16 heeft veel hardware-functies die op Linux niet zomaar werken: fa - 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: MUX-schrijffouten in bepaalde scenario's gefixt, 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. De "MUX-schrijffouten"-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. +**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" >}} @@ -446,7 +446,7 @@ Kernel 7.0 is in april 2026 uitgebracht en CachyOS pakte het snel op. Voor deze ### 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; bij de gebruikelijke cyclus van 9-10 weken 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. +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) diff --git a/src/content/docs/known-issues.md b/src/content/docs/known-issues.md index fadb6c2..c08d99a 100644 --- a/src/content/docs/known-issues.md +++ b/src/content/docs/known-issues.md @@ -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 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 "resolved MUX write failures in certain scenarios," 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, not on the version string alone, so verify against `asusctl info` and check for the mode-switch symptoms below before assuming it's fixed on your system. +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. diff --git a/src/content/docs/known-issues.nl.md b/src/content/docs/known-issues.nl.md index 87a9c28..576ff38 100644 --- a/src/content/docs/known-issues.nl.md +++ b/src/content/docs/known-issues.nl.md @@ -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 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 "resolved MUX write failures in certain scenarios", wat overeenkomt met deze bug. Of een installatie 'm heeft hangt af van of het distro-pakket al is bijgewerkt naar `6.5.0`, niet alleen van het versienummer, dus check dit met `asusctl info` en let op de mode-switch-symptomen hieronder voordat je aanneemt dat het op jouw systeem is opgelost. +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. diff --git a/src/content/docs/networking/mt7925-wifi-performance.md b/src/content/docs/networking/mt7925-wifi-performance.md index fa4b967..2f01357 100644 --- a/src/content/docs/networking/mt7925-wifi-performance.md +++ b/src/content/docs/networking/mt7925-wifi-performance.md @@ -155,7 +155,7 @@ 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 driver gets touched most months, not once a year. +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 %}} @@ -167,4 +167,4 @@ Recent proof that this is moving, not stalled: a [patch skipping scans during su - [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): the community fix set from the "Where to follow active development" list above, now installable without hand-patching -- a sign the fixes are stabilizing enough to package. +- [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. diff --git a/src/content/docs/networking/mt7925-wifi-performance.nl.md b/src/content/docs/networking/mt7925-wifi-performance.nl.md index 842c638..0ee64fb 100644 --- a/src/content/docs/networking/mt7925-wifi-performance.nl.md +++ b/src/content/docs/networking/mt7925-wifi-performance.nl.md @@ -155,7 +155,7 @@ Er wordt nog steeds actief aan deze chip gewerkt; er landden patches nog deze we - [ratatoskr.run](https://ratatoskr.run/): een beter leesbaar webarchief van dezelfde mailinglists. - [github.com/openwrt/mt76](https://github.com/openwrt/mt76): spiegel van de driverbroncode, makkelijker te doorbladeren dan de kernel.org-tree. -Recent bewijs dat dit beweegt, niet stilstaat: een [patch die scans tijdens suspend overslaat](https://ratatoskr.run/linux-mediatek/2026/04/3520789) landde in april 2026 om command-timeouts bij resume te stoppen, en een [mt7925-firmware-update](https://ratatoskr.run/linux-wireless/2026/08/17426467/t) ging uit in augustus 2026. Geen van beide is op zichzelf spectaculair, maar het tempo is het punt: deze driver wordt de meeste maanden aangeraakt, niet één keer per jaar. +Recent bewijs dat dit beweegt, niet stilstaat: een [patch die scans tijdens suspend overslaat](https://ratatoskr.run/linux-mediatek/2026/04/3520789) landde in april 2026 om command-timeouts bij resume te stoppen, en een [mt7925-firmware-update](https://ratatoskr.run/linux-wireless/2026/08/17426467/t) ging uit in augustus 2026. Geen van beide is op zichzelf spectaculair, maar het tempo is het punt: driver en firmware voor deze chip worden de meeste maanden aangeraakt, niet één keer per jaar. {{% /details %}} @@ -167,4 +167,4 @@ Recent bewijs dat dit beweegt, niet stilstaat: een [patch die scans tijdens susp - [MT7927 WiFi on Linux: Making It Work](https://jetm.github.io/blog/posts/mt7927-wifi-making-it-work/): de community reverse-engineering-inspanning achter MT7927-support. - [Known Issues, Linux MT7921/MT7925 WiFi Driver Fixes](https://zbowling.github.io/mt7925/issues/known-issues/): een lopende lijst van chip-niveau issues en hun 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 verhaal over hoe MediaTek's Wi-Fi 7-support van "niet te ondersteunen, vervang de kaart" naar actief geüpstreamd ging -- nuttige context voor waarom de situatie van deze chip er over een jaar beter uitziet dan vandaag. -- [MT7925 WiFi Driver Fixes, nu als DKMS-package](https://community.frame.work/t/mt7925-wifi-driver-fixes-now-available-as-dkms-package/79777): de community-fixset uit de lijst "Waar je actieve ontwikkeling volgt" hierboven, nu installeerbaar zonder handmatig patchen -- een teken dat de fixes stabiel genoeg worden om te packagen. +- [MT7925 WiFi Driver Fixes, nu als DKMS-package](https://community.frame.work/t/mt7925-wifi-driver-fixes-now-available-as-dkms-package/79777): een community-fixset voor deze chip, nu installeerbaar als DKMS-module in plaats van handmatig patchen -- een teken dat fixes voor deze chip stabiel genoeg worden om te packagen voor eindgebruikers.