[SOLVED] Headset Mic on AMD FW13 running Fedora 39

Framework Laptop 13 Linux
2

This has been hit and miss, depending on various distro releases. Which generation board was this for as it may need re-validation? We’re testing against 13th and AMD 7040 right now.

3 
# dmidecode
<snip>
System Information
        Manufacturer: Framework
        Product Name: Laptop 13 (AMD Ryzen 7040Series)
        Version: A7
        Serial Number: FRANDGCPA7337400CG
        UUID: 698b594e-6451-ee11-9e16-223588900103
        Wake-up Type: Power Switch
        SKU Number: FRANDGCP07
        Family: Laptop
</snip>

I am using a Steelseries Arctis 7 using the audio cable only for what it’s worth.

1 Like
4

Interesting, I use a Steelseries Arctis 1 myself, but I don’t use wired - I use wirelss. I assume this is 3.5mm jack (based on your conf edits)?

I will have to test this with my Steelseries Arctis 1 when I return to my office on Monday. Not sure if I still have a wired connection for it still. My only wired connection I use is USB with another headset.

5

You are correct. I do this mostly because I am too lazy to plug it in for charging and I worry about the battery charge state. I mostly use it to listen to music while working.

6

@Tim_Bosse Can you share the content of the alsa.conf file below?

$ cat /etc/modprobe.d/alsa.conf

I have never used the <<< (the document). But in your command on the first comment, possibly the echo is written in the file. I think it’s wrong. How did you find the command? In the Framework’s Fedora 39 installation guide?

Here is a simple test on my local.

$ tee a.conf <<< "echo options"
echo options

$ cat a.conf
echo options
7

Based on what I see in this thread

this (or something very much like it) was resolved upstream (kernel/alsa) for previous generation(s)

Perhaps needs another go-around for the new model?

8

That was a typo on my side. I had permission problems with sudo echo "..." > /etc/someplace. That’s why the here doc redirection. I errantly left the echo in there. I updated the original post.

9

I see. Okay.

The permission problem is expected. I think that the following command works with tee (new) and tee -a (append)

$ echo "options snd-hda-intel index=1,0 model=auto,dell-headset-multi" | sudo tee /etc/modprobe.d/alsa.conf
1 Like
10

I believed we were past this, but perhaps not. I have a standard 3.5mm headset I can test this again with Monday.

11

The FW13 is also using the ALC295. It appears to have the same proboem. The only difference is the PID. I created the following patch against staging kernel and tested it:

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b7e78bfcffd8..bc3b3f00feb1 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -10090,6 +10090,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
        SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
        SND_PCI_QUIRK(0x8086, 0x3038, "Intel NUC 13", ALC225_FIXUP_HEADSET_JACK),
        SND_PCI_QUIRK(0xf111, 0x0001, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
+       SND_PCI_QUIRK(0xf111, 0x0006, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),

 #if 0
        /* Below is a quirk table taken from the old code.

The headset now works as expected. I was tempted to just submit, but I’ll leave that for the Framework team to decide what to do.

5 Likes
12

Has the patch been submitted for inclusion upstream? If not, would you be upset if I did?

1 Like
13

Not at all, please do! Thanks!

1 Like
14

I’m on Ubuntu with the 13" AMD chupset and had this issue as well. I have a TRRS input for a Stackmat timer (it’s for speedcubing) and it works with 2 other Ubuntu machines I have.

I did

sudoedit /etc/modprobe.d/alsa-base.conf

which is a safer option than the tee one above as the tee command will obliterate your current alsa-base.conf file.

I put

options snd-hda-intel index=1,0 model=auto,dell-headset-multi

at the bottom. I tried a few variations, e.g. removing each of the model values but this is the only combo that worked.

I don’t know what the options specify so it’s hard to know if removing one or two is valid.
Either way, it works now with a TRRS connection in Ubuntu 23.10.

James.

15

Reach out to the alsa Devs and let them know the PCI ID of the card and, that it needs these quirks they are pretty good about adding fixupa upstream into alsa

16

I have a patch already. I thought framework was going to submit, but not yet. I plan on submitting sometime this weekend.

1 Like
17

Delighted to hear the later release provided support for this.

Looks like @Tim_Bosse is already on this - awesome!

18

Waiting for the alsa-devel moderators to let my patch through.

19

After stumbling a bit and getting some guidance on how and who to send to, the patch will be merged. [PATCH] ALSA: hda/realtek: add new framework to quirk chain

3 Likes
20

Now, I Just have to remember in about a years time, when the new ALSA code is out and I’m running it to remove the extra line from /etc/modprobe.d/alsa-base.conf.

1 Like
21

To be fair, they moved quickly on it. I received notice from kernel maintainers that the patch landed in the branches for the next 6.6 and 6.1 kernel releases.

1 Like