Problem with sound on your laptop.
Problem with sound on your laptop.
A brief explanation of the issue: no official driver configuration exists in the kernel, which is HP's responsibility. They introduced this hardware setup without updating the mainline kernel, making it unsupported. I don't apply patches for personal preferences, but if it works for you, I can help create a fix.
I understand your perspective on HP patching this issue, though they also offer Linux laptops that have weaker specifications. I chose a Windows-based HP laptop and installed Linux because it provided better performance. Regarding the hdjackretask command, I used it to adjust the pin configuration as you suggested, but the settings would reset after rebooting. It might be related to PipeWire. I’m not sure of any reliable online guides for kernel patches, but I’d appreciate suggestions on where to find more information so I can handle similar tasks better in the future. Thanks again.
When executed as root, clicking "Apply boot override" should place the mappings in /lib/firmware/hda-jack-retask.fw and register them in /etc/modprobe.d/hda-jack-retask.conf. Ensure both files exist and the process doesn't apply at boot; then share the contents of /lib/firmware/hda-jack-retask.fw so a wrapper script can be created.
HDA Analog"|awk '{print $2}'|sed 's/://') #get the card info and format it CARD="hwC${card}D0" #apply the pin settings echo "0x12 0x411111f0" > /sys/class/sound/* CARD="hwC${CARD}D0" #write the configuration echo "0x13 0x40000000" > /sys/class/sound/${CARD}/user_pin_configs echo "0x14 0x90170151" > /sys/class/sound/${CARD}/user_pin_configs echo "0x17 0x90170110" > /sys/class/sound/${CARD}/user_pin_configs echo "0x18 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x19 0x03a11040" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1a 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1b 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1d 0x40600001" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1e 0x90170150" > /sys/class/sound/${CARD}/user_pin_configs echo "0x21 0x03211020" #update the kernel config echo 1 > /sys/class/sound/${CARD}/reconfig You might hardcode the path but booting with a USB headset could cause issues, so checking inside the script is safer. Save this as /bin/soundcard_start.sh" chmod u+x /bin/soundcard_start.sh run soundcard_start.sh as root and verify it works. What init system are you running? Then we can create an automation script to launch it at boot.
You executed the script but encountered an I/O error. The pin configuration was updated in hdjackretask, yet audio isn't functioning. The files created by the script aren't present yet, which might explain the issue.
The line that triggers the update actually bypasses the config changes. It seems pipewire is blocking the process. Consider running killall -SIGKILL pipewire; echo 1 > /sys/class/sound/hwC1D0/reconfig Read this as well: https://www.kernel.org/doc/html/v4.17/so...figuration and check the Early Patching section. This ensures we're aligned with the same changes.
It turns out I misused the chmod command and after fixing it I encountered an error stating the device or resource is busy. The second command reported no such file or directory. To be clear, I also reviewed the link you provided and after further investigation, tried playing audio on Debian Linux with PulseAudio, which suggests the issue isn't related to audio configuration.
It seems the sound server relies on the device you're attempting to change. I haven't used pipewire before, so I don't know how to stop it. I'd suggest uninstalling it until ALSA functions correctly, though your package manager might also remove dependencies, making your DE vanish. If anyone knows how to halt pipewire's autostart or run a global daemon, that would help now. As mentioned earlier, you can't apply changes while it's active—good practice. You could switch to a tty console, shut down the UI, and reduce pulseaudio at once. When testing audio, use aplay -D hw:1,0 sample.wav, but since the kernel/distro is different, you should check what sound path is being used (`card 1 device 0`) and run aplay -l first. Need to figure out the issue, break the command into parts, and identify which one triggered the error, then list the directory it's targeting.