[GUIDE] Successful Wi-Fi 7 (802.11be) on Framework 13 AMD with Qualcomm QCNCM865 and Arch Linux

Yes it was easy and no I don’t think you need anything else. Now we wait for upstream to merge it and/or qualcomm to upgrade the ID and firmware : [GUIDE] Successful Wi-Fi 7 (802.11be) on Framework 13 AMD with Qualcomm QCNCM865 and Arch Linux - #176 by GreyXor

So to be clear: is this released on Arch yet? I’ve been waiting for the BT fix before I put mine back in.

That’s nothing related to arch. basically : I’ve found the cause of bt audio issue. I send my patch to linux, we have to wait that they accept and merge it. Until then you can compile yourself your kernel with my patch.

1 Like

Gotcha, I’m not really familiar with the process of adding changes and how they get added to the kernel or where they even go in the first place. That being said, I clearly am not skilled enough to compile it myself. I’ll hang tight till someone says its work on patch 6.X.

Thanks!

2 Likes

I am also in your shoes. Linux users come from all different backgrounds and skills. I don’t know how to compile custom kernels.

@morjuosu @Techie_Zeddie Honestly, it’s more of a question of desire (and free time) than one of skill; I compiled a custom kernel as a preteen knowing absolutely nothing about C and not that much about Linux—the allure of those proprietary AMD OpenGL drivers was just that strong. (Farewell fglrx, you won’t be missed.) What makes it a bit more difficult is doing it well, e.g. following your distro’s existing build process or even making it work across kernel updates. I won’t blame you if you decide the hassle isn’t worth it for you, I just don’t want you to think that this requires some sort of deep Linux knowledge.

If you use NixOS, reference the desired patch file from boot.kernelPatches, nixos-rebuild boot, and reboot. If you use Guix, I expect it has something very similar.

If you use Arch Linux or a derivative, building packages is simple enough that the easiest route is probably to download the sources for the kernel package and build a patched version of it using the generic instructions for patching packages (note that updating it afterwards to follow the version in the repos will be on you).

Otherwise, your distro is probably already integrated with DKMS for (re)compiling as necessary any proprietary or out-of-tree kernel modules[1] that its users have the misfortune to require. Here’s a guide that shows how to convince it to build patched versions of in-tree modules (you’ll want to use ath12k and the correct patch in place of btusb):

If none of the above works, you can grab the sources from kernel.org, patch them, install the build dependencies, decompress the configuration from /proc/config.gz on your running system to .config in the source root, and type make. That’s the easy path my preteen self took, but if you’re updating your system regularly (I wasn’t), you’ll need to figure out where to install your freshly built kernel in order to avoid conflicts with your distro’s package manager.

Finally, you can always track down your distro’s IRC channel and ask there.


  1. In a typical kernel build, most of the hardware support exists in separate dynamic libraries that it loads on demand, known as “modules”. “In-tree” modules are modules whose source code is maintained as part of the kernel itself; any others are “out-of-tree”. ↩︎

2 Likes

Yeah! And at least under linux we can change it. example with Windows, we cannot apply the “even low brightness patch”. under linux we can. but that out of subject

Thank you for the patch. My BT audio works now.

Glad to hear, enjoy

I tried the MT7925 again since it’s been a while and I have a bunch of them, and they appear to be working well and stable now. I can also get better link speeds compared to Intel (AX210), especially for upload. Speed tests for downloads are similar but upload is much faster.

I also tried the Qualcomm chip again and it appears to still be buggy. It would lose the connection trying to start a speed test.

Note my kernel version is 6.12.6-arch1-1.

Thanks, strange I don’t have any issue with wi-fi under linux 6.12.7 and 6.13rc4.

Do you have any problem with Bluetooth with MT7925?

Or it just works on 6.12 (both wifi7 and bt)?

I don’t have MT7925, only QCNCM865

The only thing I generally use Bluetooth for is for a wireless mouse; I connected my MX Anywhere 3 and used it for a bit just to make sure it worked and it worked fine.

I didn’t spend very much time trying to figure out why it wasn’t working… since the MediaTek worked, and I have more of those, that ended up being what I ultimately went with.

That said I’ve previously had issues with Qualcomm/Atheros cards, for instance on an XPS 13 9310 that had some Qualcomm 802.11ac card (using the ath10k driver) soldered down and initially had similar problems and even after it started working, always had random problems with it on Linux. So I was really hoping that Qualcomm wouldn’t have been the answer for me anyway.

Unless I run into problems with these MediaTek cards, or I really want 320Mhz bandwidth cards, I think I’m done experimenting and am going to stick with the MT7925 for the foreseeable future.

If you have Bluetooth headset it will be very useful to be sure that it works.

(If not, I will try to buy WiFi card and test)

Qualcomm AX cards are very stable on Linux.

Problems I had with other cards:

  • AX210, AX200. High power consumption when power-saving modes are enabled. Not dissimilar to this: Linux on the Dell XPS: Fixing AX201 Wi-Fi performance | Jonathan Bowman. The experience was pretty sordid.
  • Mediatek RZ616. General packet loss issues after resuming from sleep. My general impression of the company from embedded/mobile devices is poor, I only have this as the laptop came with it.
  • QCNFA222. I tried this in response to the above issues, reasoning that if any driver’s going to work well, it’s ath9k, the original free Linux wireless driver. I had problems with packet loss and other issues after resuming from sleep which were hard to pin down. I wrote about these elsewhere, AMD IOMMU seems to be a problem, sometimes the card was only operational after rebooting.

(My sense is that some of these issues may arise from the interaction with the AMD platform firmware, but it’s hard to say.)

I have that NFA765 card as well as a Compex WLT639. WLT639 has Bluetooth on UART which doesn’t appear to be routed operational on Framework 16, I can’t tell from the datasheet if it goes anywhere useful. It is an industrial/embedded card with higher transmit power and I use it for wireless hotspots. Performance on these is very good and NFA765 is considerably cheaper than successor 865 and easy to source locally. Linux wireless has always been difficult and prone to these sort of issues due to disinterest from manufacturers, so I really value stable and consistent performance. Speed is excellent.

I also have a U-blox NXP (ex-Marvell) card, but they are not suitable for most laptops as the driver support is not in mainline and they use the larger U.FL antennae. These have good performance but are for industrial/embedded/networking e.g. set-top boxes or networking gizmos.

Hi @GreyXor i took kernel version 6.13.0rc5 and applied your patch for Bluetooth audio, at the beginning the patch was working perfectly with my AirPods pro 2 but after a few days it stopped, i tried unpairing device, reboot and then re pairing device but it didn’t work.

I can also see that the device get detected as input in the kernel log:

[   43.477156] input: Someone’s AirPods Pro (AVRCP) as /devices/virtual/input/input20

Do you have any ideas which may help please ?

Also, i see that your patch didn’t passed the iso test, did the patch get accepted ??

Hi, sorry no idea, maybe the audio profile has changed ? Check LE Audio, AVC etc.
no idea either when they will accept it, I got no answer yet.
The ISO test shouldn’t be a big deal, it’s just a warning

@GreyXor Okay, i finally get it, i have different PID, see the lsusb output:

Bus 001 Device 005: ID 0489:e10d Foxconn / Hon Hai

Also i made a patch for my id and it got accepted: Bluetooth: btusb: Add new VID/PID for WCN785x - kernel/git/bluetooth/bluetooth-next.git - Bluetooth kernel development tree

I think your patch is lost, maybe you should check that, see the time window on the commit (about 5 days)

1 Like

Thanks!
I mailed Qualcomm maintainer about that and they sent this : Bluetooth: btusb: Add 14 USB device IDs for Qualcomm WCN785x - Patchwork
So lot of new PCID now :slight_smile: