Since many years the ath9k driver support 450Mbit(3TX/3RX) on 2.4Ghz and 450Mbit(3TX/3RX) on 5Ghz is the reference for a Wi-Fi driver that can run with only opensource software. Recently there is kind of rare ath9k capable hardware released with (600Mbit)4TX4RX but the ath9k still supports on it 3 streams: https://github.com/openwrt/openwrt/pull/9389
The famous wiki here also does not show anything new since years https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers
As far as i know @nbd is still been payed for creating Wi-Fi 5 and 6 drivers to work together with closed source software and is not being payed to create fully opensource driver like he did before mainly with the ath9k.
Is there in 2022 still no 802.11ac hardware that can already run without closed source software? Is there some recent development in this direction?
How can you see in all the upcoming human future on this planet?
For example maybe @nbd at some point gets angry at MediaTek and release all the source code of the at the moment closed source binary blob. Or maybe someone get into the servers of MediaTek and release the source code from there.
For example there is now the release of the opensource NVIDIA GPU driver. Everyone was telling for years that this would never happen. Then some people just got into the NVIDIA servers and took the source code and told NVIDIA, that if NVIDIA wont release a opensource driver, they would release all of the code from their servers by themself. Shortly after that NVIDIA released the driver to the public.
I know about Wi-Fi 6, Wi-Fi 6E (802.11ax) and the unreleased Wi-Fi 7(802.11be). It would also be nice if this hardware could run without closed source software.
Maybe someone else know something about some future hardware that respects the freedom of the people or a project that is helping to achieve this with existing hardware.
OpenWrt wouldn't be able to use any illegally leaked source-code, mate. Copyrights don't just vanish into the wind like that.
NVIDIA was already working on the open-source code before that. The hack has nothing to do with the newly-released open-source driver. Besides which, you completely missed the fact that the driver isn't blobless, either -- the entire userland is still proprietary code and the driver also requires the proprietary GSP-blob to be loaded into the kernel to work.
Yes, i know that. The now released kernel module is not like Nouveau combined 700 series or older card that could run without any blobs. I have not missed that. I just did not like to write and endless long text that have not anything to do with 802.11ac. It was just a example as an answer to the person who told to be able to look in the whole future of our human existence:
Lets get back to topic. Maybe someone know some project that i have missed that could lead to a fully open 802.11ac driver.
The driver that NVIDIA released is nothing but a way for them to be able and utilize GPL only exported symbols without using their "GPL condom", it is nice to see them move into open-sourcing even just this part.
But that doesn't really change the fact that they basically moved most of the driver into a firmware blob that runs on the card itself with an unstable API to the driver and that the userspace is still binary only.
Hopefully, they will reach the AMD level of GPU support in Linux in the following years.
I don't have a crystal ball but I have been in the WLAN market for a while now and I can see the way things are moving.
They are moving exactly the opposite of what you want, into more and more offloaded firmware instead of an ath9k-like situation that had no FW.
OpenSDR-s attempt is the closest you are gonna get to a fully open WLAN implementation, but that is not really commercially viable as its all FPGA based
To answer your question, no. ath9k is actually effectively closed-source, it just implements the n standard in hardware and not software.
The real advantage of minimizing closed-source components is maximizing community-modifiable components. mt76's firmware blobs handle components of the standard that happen too quickly for the Linux host to be able to respond -- RTS, CTS, aggregation, and so on -- while leaving swaths of the hardware open to be pushed around by the host.