FS#78565 - Lenovo ThinkBook 16p G4 IRH internal speaker too low
Attached to Project:
Arch Linux
Opened by Huayu Zhang (Tanche-Z) - Sunday, 21 May 2023, 15:09 GMT
Last edited by Toolybird (Toolybird) - Saturday, 27 May 2023, 00:14 GMT
Opened by Huayu Zhang (Tanche-Z) - Sunday, 21 May 2023, 15:09 GMT
Last edited by Toolybird (Toolybird) - Saturday, 27 May 2023, 00:14 GMT
|
Details
Description:
The Lenovo ThinkBook 16p G4 IRH uses a Cirrus AMP for internal speaker, so that even the codec of Realtek soundcard works properly (in headphone jack), the speaker are still too low and the ACPI Error keeps showing during boot and power off. Additional info: * package version(s) * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: 1. newest packages (sof-firmware, alsa, pipewire...) 2. New laptop that use Cirrus for AMP and Realtek for codec. (The Cirrus should be work properly with Realtek soundcard together so that the internal speaker can output at a acceptable volumn level) |
This task depends upon
Closed by Toolybird (Toolybird)
Saturday, 27 May 2023, 00:14 GMT
Reason for closing: Upstream
Additional comments about closing: See comments
Saturday, 27 May 2023, 00:14 GMT
Reason for closing: Upstream
Additional comments about closing: See comments
[1] https://wiki.archlinux.org/title/Kernel#Debugging_regressions
And Ubuntu developer also tried to do something. But didn;t fix for my laptop: ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1965496 )
Possible solution:
- Your BIOS needs to behave correctly to report the _DSD information in ACPI for the Cirrus device.
- Once when BIOS is proper, HD-audio Realtek codec needs the binding with Cirrus sub-codec driver. It needs the quirk entry.
If the same quirk is applicable, you may try to pass the model option with the existing PCI SSID as alias. See Documentation/sound/hda/notes.rst.
Note that, on AMD platforms, the Realtek codec appears at the secondary instance, hence you'd need to pass to the second argument of model option, e.g.
model=,103c:8975
So we have to wait...
But the patch won't be accepted in the tree. Because those are gussing value and may damage the hardware.
We should wait for Cirrus and Lenovo add some quirk into the kernel (or Lenovo may update their BIOS)
Ick! :/
Thanks for following up. It's good that you have a workaround. Clearly an upstream issue...but nothing Arch can do here.