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