I will probably speak on behalf of many people who prefer to wait patiently for @MrChromebox and the team to continue to work the the firmware.
@avieth but thank you for sharing your findings that can be beneficial for someone who can’t wait for the firmware update and will consider to compile their kernel.
I’m not sure setting the jack type to CTIA is necessary, or that the coefficient value 0xd429 is correct - the Linux driver uses 0xd489 for the ALC256 (and others). But it doesn’t seem to have an effect either way.
Setting the jack detect to auto (setting coefficient 0x4a to 0xe) works for the headphone/output, but causes the external mic to register as always connected. We can work around this by disabling the jack detect on the external mic (and making it manually selectable) but that’s what we have now, so only improvement is the headphone jack detect. Which works exactly once, and then gets stuck inserted (at least on kernels 5.14 and earlier)
Did it not make the microphone input work for you? For me it made the jack detect work for the output device but not the input, but the main improvement is that the mic input actually produces a signal.
yes, leaving JD off for the mic and manually selecting allows the external mic to work, albeit with significant background noise
Hello @MrChromebox! I am curious if there has been any progress made to make Microphone via 3.5 Jack to work?
nothing ready for testing yet. Still working on tweaking things so jack detection/removal works (consistently), mic detect works, and the noise floor of the external mic is low end to actually be usable
Any sort of very rough eta on this fix?
no. The registers controlling these things are entirely undocumented
I did a bit more tinkering recently and found another way to get the same results as my prior “half-workaround” from earlier in this thread: set the 2nd GPIO to on, direction 1, data 1, so that it appears like this in /proc/asound/card0/codec#0
GPIO: io=3, o=0, i=0, unsolicited=1, wake=0
IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[2]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0
This can be done by verb’ing the 0x01 node like so:
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x04
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x04
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x04
I have no idea what this means or why it might be so, just throwing it out there in case it might be useful to anyone else.
so where did it come from?
Trial and error. I browsed through recent commits to patch_realtek.c which mention the ALC256, and also tried a few of the model name quirks.
Has there been any progress on getting an external microphone to work via the jack? It’s still quite inconvenient to do video calls from the laptop while traveling, as my wired headset microphone doesn’t work, nor does two other Bluetooth headsets I’ve tried (including fairly generic Pixel Buds) though I imagine this latter issue is perhaps Linux Kernel related.
At home I use an external USB microphone that seems to work well.
I’m running latest version of Manjaro w/ all updates, and just updated Coreboot to latest. Haven’t updated EC yet, but not sure if that should have any effect?
FYI, I managed to get my Bluetooth headsets (Pixel Ear Buds, HyperX Bluetooth Headset) working using the pipewire-pulse drop-in for pulseaudio (as per https://forum.manjaro.org/t/what-is-the-correct-way-to-install-package-manjaro-pipewire/49738/7). So at least the more immediate annoyance is resolved for me.
Would be nice to get the wired microphone jack to work though…
Did you miss a hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04 in the code lines, or should it have read “data=0” in the file above?
@Kyle_Rankin - what is Jonathon Hall’s tag on this forum? I understand from “Reboot loops” post he now deals with the firmware. Please confirm.
Hi @kate.mason, sorry for the delay seeing this. There is a lot of background here to catch up on, so I want to assess where we currently are, check out any work that was in-progress, and go through the suggestions from this thread. I hope to have another update for you soon regarding where we are and what steps I think we can take next.
I think I’m running into this same issue with Qubes OS v4.1.1. The microphone does not produce any signal levels when plugged into the 3.5mm audio jack on the right side of the Librem 14.
The dom0 volume control panel => Input Devices => Built-in Analog Stereo => Port: Microphone shows no activity when speaking into the mic, and yes I have made sure to turn the camera/mic switch to the ON position.
When I connect a USB microphone, it does not even show up as an input device in same control panel, however I can attach it to a VM and get audio out of it.
I did some more testing and I can get the built-in microphone next to the camera working with VMs after flipping the hardware kill switch and attaching the dom0:mic device to a Qube VM.
It’s the 3.5mm stereo audio headphone jack on the right side that I’m still having issues with. Does anyone know what the name of this device should be?
Any updates on the firmware fix? Would prefer to use my 3.5mm plug headset to conduct calls. I have the Librem-EC 1.11 fireware installed on my Librem 14 and am still struggling with this.