That issues list is misleading since the mt76 covers a multitude of devices, all of which report issues to the same place.
Support for a device will go for a long as there is someone who wants to maintain it. Even the 4/32 devices could be maintained to receive security updates backported to a version of OpenWrt they can run - but only if someone wants to invest the time and effor to do so. And if it happens, it'll be someone like you @BenSisko who does it for their own device because no one else has, and if someone else happens to get use of it, well, that's ok too..
I just added OpenWrt support for a device that was 1 of less than 500 and the ODM went under in 2015 :D. Doesn't mean it can't be supported.
I totally agree. I can't say objectively if one driver has less issues then mt76 but my sense of it is that at least like you said with community effort and interest, all of these issues can be addressed because of mt76's openness. At least we're not stuck with a binary blob from some corporation that we can't hack away on. Would be interesting to see a comparison of other driver issues that are a result of blobs. Thanks for making openwrt a little more ubiquitous.
I know it's wandering off topic, but with MT being as "supportive" of the aftermarket firmware community, has anyone actually out-reached to them about testing their home-grown drivers as they Pre-release and dev them? Nothing breaks code faster than a user touching it, and they might be open to the assistance.
If that is the case, and it very well might be (I honestly was asking the question I did because I don't know), then I wonder why any compatibility/driver/blob issues are present. If they aren't beholden to BCom/QComm (someone mentioned they roll their own drivers?), then that any outstanding issues exist is.. disheartening..
I was under the impression there might be a few MT employees contributing in their spare time, and was asking if anyone had formally approached them to say "Look, lots of people like your stuff. You've got people who want to help make it the best it can be, and in the process, you get to reap everything gained from it internally because it's opensourced..."
In my experience, you should never, ever, let developers and programmers talk to your end-users. The OpenWrt community is a place that bridges the gap between the engineers and programmers and the "general informed public". Present it like that and maybe they'll ready-up some resources.
Ok, I didn't know he works for Mediatek. Still, is he employed by them to do this or just does it in his free time? Frankly both answers suggest MT doesn't care.
Keep in mind that MediaTek contributing to the Linux kernel doesn't mean they contribute to OpenWrt directly. I just mention it because of the previous links connecting MediaTek as examples both point to outside of OpenWrt.
I still think one of the keys to improving the OpenWRT WiFi implementations is to address the points I made in the quote, and to additionally define/create testing procedures.
One the best ways to get devs to address a given issue is to document it well, and importantly, give them a reproducible scenario and clear acceptance criteria for the fix.
Thanks Felix for bringing MT76 to people. I'd say no driver is 100% perfect, especially it supports plenty of old devices which are no longer maintained even inside MTK.
Open source and community-driven software development is becoming increasingly important to the wireless industry, so MTK folks actively join this party starting from MT7615. So, of course, the quality of newer devices are better than legacy ones. MTK also did some basic quality/performance tests for MT7915 (and future chipsets).
If someone would like to run some newer features like BPF that utilizes newer kernel, then I believe MT76 will be one of good solutions
