It’s great of you folks to be on this. Thank you!
I believe this is the right patch:
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4c0c593f3c0a..a1b45c72e9b1 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9294,6 +9294,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
+ SND_PCI_QUIRK(0xf111, 0x0001, "Framework Laptop", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
#if 0
/* Below is a quirk table taken from the old code.
I am assuming that the subsystem ID f111:0001
is unique to this revision of the hardware ; I preferred it over 8086:a0c8
, which might match too broadly any TGL-LP SST devices.
With that patch + sound debugging enabled:
[ 823.593494] snd_hda_codec_realtek hdaudioC0D0: ALC295: picked fixup Framework Laptop for PCI SSID f111:0001
[ 823.593502] snd_hda_codec_realtek hdaudioC0D0: ALC295: Apply pincfg for Framework Laptop
[ 823.593505] snd_hda_codec_realtek hdaudioC0D0: ALC295: Apply fix-func for Framework Laptop
I’ll submit it to alsa-devel
in a couple hours
Alright, here you go! Mailing list, Patchwork. I’ll update this thread as its status changes.
Thanks for the confirmation, Kieran!
Any particular reason to do the fix that gives a non-working microphone device (in addition to the working one) instead of the one that doesn’t?
Nope! I didn’t know there was an alternative fix.
I’m testing out a variant of it based on the pre-existing System76 “No Headphone Mic” quirk:
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4c0c593f3c0a..54442ec36af9 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7012,6 +7012,7 @@ enum {
ALC245_FIXUP_CS35L41_SPI_4,
ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED,
ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED,
+ ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -8806,6 +8807,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC285_FIXUP_HP_MUTE_LED,
},
+ [ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1913c }, /* use as headset mic, without its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -9294,6 +9304,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
+ SND_PCI_QUIRK(0xf111, 0x0001, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
#if 0
/* Below is a quirk table taken from the old code.
I’m seeing a little bit of trouble where the headset mic doesn’t report the right levels after coming out of sleep. However, connecting to the NO_HP_MIC
quirk chain feels appropriate. The pinmux config in the above patch is based on the dell-headset-multi
one without the headphone mic.
I will of course look at your pinctl as well.
Alright, I think the “right” pinctl value is 0x02a1112c
hda-emu % ./hda-decode-pincfg 0x02a1112c
Pin Default 0x02a1112c: [Jack] Mic at Ext Front
Conn = 1/8, Color = Black
DefAssociation = 0x2, Sequence = 0xc, Misc = 0x1
The one you produced is “Mic at Ext Left”, which is totally correct. However, the Headphone Output is designated as “Ext Front”. Figured I’d line them up.
The one used by dell-headset-multi
is Ext Rear/Pink/Association-0x3
.
The final version of the patch incorporating @Brad_J’s suggestion was accepted into the alsa dev tree!
Fantastic! Thanks, guys!!
Which version will be the first released stable kernel version including this patch? 5.18? Can this patch be backported to the kernel 5.17 too?
If I had to guess, the first release that could contain this fix is 5.19!
Does anyone fancy taking a stab at this too?
I see. Maybe someone can ask a backport request in Linux distros if they want to see the fix faster. Today I tried to ask the backport request to Fedora 36 (kernel 5.17) on Fedora. But I gave it up today, as I needed to show the reproducing steps, and I didn’t have the motivation. (the detail).
One of the maintainers of the stable tree let me know that they pulled this in for an update to kernel 5.17.
Alright, here’s the final update.
This patch is available in:
- 5.19-rc1 (mainline)
- 5.18.1+ (stable)
- 5.17.13+ (stable)
If your distribution is relatively quick to update, it shouldn’t take long before you see 5.18.1 and 5.17.13 hit your package repositories.
Fedora 36 is now on 5.17.13, and the headset workaround is indeed no longer needed!
Fedora 36’s latest kernel RPM is 5.17.13 [1]. But the guide [2] says to download the Fedora ISO image from [3], right? The kernel version on the ISO is also 5.17.13? If not, perhaps, a step to upgrade the kernel by `dnf upgrade might be needed on the guide not to see this issue.
[1] Overview - rpms/kernel - src.fedoraproject.org
[2] Fedora 36 Installation on the Framework Laptop - Framework Guides
[3] Download Fedora Workstation
Yes, I included a reminder in the guide that folks should update their packages.
OK, I found it.
Make sure to update your packages using “sudo dnf update” or the Software app to get the latest kernel version, which includes further improvements for the latest Intel CPUs and for the Framework Laptop specifically.
But a small issue is here. It’s not dnf update
but dnf upgrade
. The dnf update
works, but it is a deprecated alias of the upgrade
.
$ man dnf
...
Upgrade Command
Command: upgrade
Aliases: up
Deprecated aliases: update, upgrade-to, update-to, localupdate
...
Thanks, updated the guide.