I’m not familiar with how to do that.
In addition to @csp my card also has an other PID.
It has VID: 0x0489 and PID: 0xe10d.
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e10d Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
After adding those to your patch and building my own kernel bluetooth audio is now working perfect! 
I’m not that talented creating a pull request for bluetooth-next…maybe you can do this?
The problem is that Qualcomm seems to be having a lot of fun creating 50 different ProdIDs. And I don’t know why they’re doing it. I’ll do an email to explain the situation
Thank you!
…maybe you can post the link to the mailinglist thread/Bugreport afterwards?
just got this message from quic_zijuhu
will up-steam updated more BT firmwares
and add batch of IDs in btusb.c
but it may take some times to complete.
we will up-stream more BT firmwares and Added serial IDs.
Sooo, I suppose it’s matter of Wait & See.
1 Like
I have this chipset on my MSI Tomahawk MAG x870 motherboard. I have 6.9.3 kernel with 22.04 jammy and ath12k driver. My card works when the computer is booted, however after about 20-60 minutes it suddenly stops working. Any ideas on what’s wrong?
I already have power management off.
$ iwconfig
...
wlp6s0 IEEE 802.11 ESSID:"RankedChoiceVoting"
Mode:Managed Frequency:5.24 GHz Access Point: 80:B9:7A:CF:FD:48
Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=0 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:178 Invalid misc:175 Missed beacon:0
...
You really want and need a newer kernel, try 6.12
1 Like
I used mainline to update my kernel in my pop-os! Do I need to do anything else? I’m gonna wait for a few hours and see if the WiFi drops again:
❯ uname -mrs
Linux 6.12.1-061201-generic x86_64
No that should be enough, how is it ?
1 Like
I was gonna post here afterwards. I updated kernel using mainline and everything is working great. The wifi has been stable and working great for the last 6 hours, and it has never gone this long without failing. Thank you!
3 Likes
Thanks for posting your submitted patch. Based on it, I created a patch for my own kernel linux-zen-dori/qcnm_btusb_ids.patch at main · Doridian/linux-zen-dori · GitHub
Was it easy to upstream your change? Anything I should keep in mind other?
I’m obviously interested in doing that as well now that I confirmed this has indeed fixed BT audio for me on my FW16.
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.
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