Actually here are full logs, it literally told me how to get them lol
I noticed that the second time i built it, im not sure what happened when i put the second release out but i think some upstream patches from 6.10 got merged in somehow and it borked it.
I just finished my 3RD ATTEMPT. Ive really never used github in this capacity so this has been a humbling experience to remind me i really need to read the github manual again.
Try this snip, ive gotten 3 successful builds with this one.
boot.kernelPackages = let
linux_zen_pkg = { fetchurl, buildLinux, ...}@args:
buildLinux (args // rec{
version = "46f7c22";
modDirVersion = "6.12.8-zen";
src = pkgs.fetchurl {
url =
"https://github.com/Mephist0phel3s/zen1-6.8.9/archive/refs/tags/46f7c22.tar.gz";
sha256 =
"sha256-2+kWjEyzjEIqRiaeJkPavDdMU92BfltY1XR06PU+Hag=";
};
} // (args.argsOverride or { }));
linux_zen = pkgs.callPackage linux_zen_pkg { };
in pkgs.recurseIntoAttrs (pkgs.linuxPackagesFor linux_zen);
MEPHIST0PHEL3S!!!
IT WORKED!!!
YESS I am so happy. Thank you!!!
I really appreciate all the help!!!
Let me know if you are going to push this to the main linux kernel or not - if you won’t I will for the good of everyone who owns my motherboard.
Thank you thank you again!!!
Sure, i can definitely send a pull request at least
I am so glad it worked! I was legit starting to have doubts xD
Yeah i def had the read the entire git manual before i really understood what was going on up there xD
Heres the git pull to the main head repo for the zen kernels, requested the change get pushed to the main as well but i know Linus doesnt use github for version control so merge and pull requests to the main linux kernel github just end up in a sinkhole.
I don’t think the zen-kernel will accept any related patches through GitHub unfortunately. See Pull requests · zen-kernel/zen-kernel · GitHub (there aren’t any merged pull requests there).
I also think this is a patch that can be applied to the upstream kernel.
There is documentation on how to submit patches there:
https://docs.kernel.org/process/submitting-patches.html
I haven’t done this myself before. It does seem a bit trickier than using GitHub. I could give it a try as it does seem feasible.
As for the commit itself, take a peek at Bluetooth: btusb: Add new VID/PID 0489/e124 for MT7925 · Mephist0phel3s/zen1-6.8.9@01649f8 · GitHub. It is a commit to the kernel for a similar change that has been accepted. I’d opt to keep the commit message similar. It’s probably useful to have such a listing from your BT device as well:
sudo cat /sys/kernel/debug/usb/devices
Also, when submitting the patch to upstream they’ll also require a name and email, which both need to be ‘real’. Your current commit uses Mephist0phel3s <132147854+Mephist0phel3s@users.noreply.github.com>
, which won’t be accepted I’m afraid )
Yeaaaah, when i totally fucked the first merge request the maintainer commented asking about it and i was like ‘halp!’
So im working on it, and yeah it its alot more involved than meets the eye.
Guy also mentioned that this would be better submitted as a patch so it can be backported downstream to the LTS kernels and such but thats a totally different process than sending a pull request. More research is required.
Also, my drivers were never an issue. It was just a particular ‘mode’ the BT had baked i patched out, i more or less permanently disabled the mic on my headphones when connected to my pc so thats not really a patch, just a really hacky work around. I hated that fucking mode anyways so im thankful to have patched it out.
Check it out:
security.rtkit.enable = true;
services.pipewire = {
enable = true;
alsa.enable = true;
alsa.support32Bit = true;
pulse.enable = true;
jack.enable = true;
};
services.pipewire.wireplumber.extraConfig.bluetoothEnhancements = {
"monitor.bluez.properties" = {
"bluez5.enable-sbc-xq" = true;
"bluez5.enable-msbc" = false;
"bluez5.enable-hw-volume" = true; ### <<< Enables touch slider on headphones for fader gain, pause, and unpause functionality
"bluez5.auto-connect" = [ "a2dp_sink" ]; ### <<< Autoconnect to HD 48khz mode on connect
"bluez5.roles" = [ "a2dp_sink" "a2dp_source" ]; ### <<< This sets the BT driver role to a2dp sink and source, which are the HD 44.1khz and 48khz module modesets but doesnt load the modules for hsp, which is the handset driver that enables the mic.
};
};
Also, since the bluez driver is also the driver package hard coded as the hard.bluetooth driver pack means that the hsp modules will never be loaded while bluez and wireplumbing are in charge.
Why go through so much effort?
The hsp modeset audio quality was so god awfully horrible it was the main reason i quit windows and nearly smashed a keyboard in frustrated rage over this exact problem.
Was in a PUBG match, top 10, 8+ kills or something and sweating my balls off and then boop, no sound. Period. Why? Modeset change when i got a discord call.
I switched to nixos THAT day and the very first thing i worked out in Nixos was this code block.
So yeah, this is not a patch. This is my own personal sanity function.