Great work! I’ve looked at the patch and noticed that my own QCNCM865 has yet another VID / PID value: 0x2C7C:0x0130. Looks like I’ll have to look into compiling my own kernel for testing…
Edit: Alright, I hadn’t tested BT audio on this card for a while and I’ve noticed that even without the kernel patch, my audio devices now seem to work without issue on Fedora 41 with kernel 6.11.8-300.fc41.x86_64 while they did not work when I last tested them. Looking at dmesg output still shows a lot of the following error:
Bluetooth: hci0: ACL packet for unknown connection handle 3805
Running a 6.12.1 kernel patched to include my VID/PID fixes that error showing up, but seems to make no functional difference to how the audio works (i.e. fine).
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
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
...
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!
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.
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.
@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”. ↩︎
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
