Can open source drivers ever be as good as proprietary ones?

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. :grinning:


Sounds like a good reason to stay away from Qualcomm products.

Do other vendors have the same predatory practices?

1 Like

Good luck with boycotting Qualcomm, if you dont like FW blobs then except for mt76 which is most open and even it has blobs there is no choice


It's still better than Broadcom selling WiFi drivers to DD-WRT and providing no usable kernel driver for softmac chipsets

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.

Aren't they already substantially contributing to mt76?

Are they contributing at all? I don't think any of the top contributors work for Mediatek.

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.

1 Like

I have no idea honestly. I thought Mediatek was officially involved/contributing by to what extent exactly I don't know.

1 Like

A quick look at the Linux wifi list shows some MediaTek email addresses. E.g.

Where did you look?

1 Like

"Ryder Lee" (Mediatek) is the person who is responsible for the MT76 opensource driver:


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.

Well, at least his email address is: ryder.lee at
For the rest, let´s ask them =>

1 Like

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.

1 Like

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.

There may be legal implications in us contributing to or hosting it.

The HVS, pixel valves, etc are all Broadcom IP, and we have documentation that can't be released


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 :slight_smile:


11 posts were split to a new topic: MT76: MT7613 radio and DFS support

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.