Bug 156311
Summary: | No PC speaker (Beep, system bell, pcspkr) when snd_hda_intel is loaded | ||
---|---|---|---|
Product: | Drivers | Reporter: | radiotubes |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED CODE_FIX | ||
Severity: | low | CC: | radiotubes, tiwai |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 4.4.14 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
output from alsa-info.sh -non working configuration -- note "Node 0xb" settings
pythton scrip to edit snd_hda-intel + realtec codec config. Fix patch ALC268 beep mixer ctl alsa info after patching debug patch alsa-info.sh output final working |
Description
radiotubes
2016-09-08 04:58:33 UTC
Created attachment 232591 [details]
pythton scrip to edit snd_hda-intel + realtec codec config.
the attached python script was generated by the hda-analyzer script provided in the alsa tools package. This script gets run via rc.modules in order to correctly configure the sound system where the pc beep (pcspkr) and hd audio (snd_hda_intel) work concurrently.
It seems this solution is not the prettiest and perhaps some editing in the kernel code could resolve it.
The driver has a code to enable PC beep on Realtek codecs (as long as there is a digital beep widget), but it's enabled only when the codec SSID has some specific bit, or when the codec SSID doesn't fit with Realtek encoding. Realtek assumes the codec SSID containing some information in their own encoding way, and the availability of PC beep connection is one of them. So, it implies that your vendor didn't set the codec SSID properly that is compliant with Realtek's requirement. You can forcibly enable the PC beep path by adding your PCI SSID to beep_white_list[] in sound/pci/hda/patch_realtek.c instead. Maybe it's a good idea to add the hint string to allow enabling / disabling the beep without recompling... Or try the patch below. It should fix the issue generically on Lenovo machines. Created attachment 232601 [details]
Fix patch
After applying the patch, try to adjust the mixer with "alsamixer -c0", and unmute and raise the beep volume.
Patch applied, no change. I have never actually had the beep mixer option in alsamixer. Question: Should I add the model option to the snd_hda_intel to properly configure the module? As is, it shows "auto". I have tried several others especially "headset-mode" as the physical jack is multi-function (headset and mic capable). If so, what would be the correct model option? At this point I have read through patch_realtek.c, hda_intel.c, the hd audio specification from intel, the data sheet for the codec chip, and any kernel documentation available. I think there must be a better way to get this working and to suit multiple platforms (not just my laptop), although very few people are concerned about preserving and using the legacy beep function. (In reply to radiotubes from comment #5) > Patch applied, no change. I have never actually had the beep mixer option in > alsamixer. Then something wrong in your side. Drop model option if you used it, for example. > Question: Should I add the model option to the snd_hda_intel to properly > configure the module? As is, it shows "auto". I have tried several others > especially "headset-mode" as the physical jack is multi-function (headset > and mic capable). If so, what would be the correct model option? Don't pass model option unless really needed. Created attachment 232731 [details]
ALC268 beep mixer ctl
I don't think anything is wrong here. The kernel is properly configured and the beep functions when I select bios config at POST time. I notice there is a specific fix-up for the ALC268 that sets up the beep mixer control, however there is nothing specifically for the ALC269. attached is the specific code for the 268. Is it possible to add this type of code for the ALC269 chip and give it a try? I did find a bug report relating to alsa that did mention the loss of the beep mixer control for the ALC269 somewhere after 2.6.35 kernel version, however I can't find it now. I don't think it was ever resolved. (In reply to radiotubes from comment #8) > I don't think anything is wrong here. The kernel is properly configured and > the beep functions when I select bios config at POST time. I notice there > is a specific fix-up for the ALC268 that sets up the beep mixer control, > however there is nothing specifically for the ALC269. attached is the > specific code for the 268. Is it possible to add this type of code for the > ALC269 chip and give it a try? The beep control *DOES* already exist for ALC269! You misunderstand the situation. In patch_alc269(), there is the following code: if (has_cdefine_beep(codec)) spec->gen.beep_nid = 0x01; and then if (!spec->gen.no_analog && spec->gen.beep_nid) set_beep_amp(spec, 0x0b, 0x05, HDA_INPUT); Once when this is set, the beep controls are added in alc_build_controls(). The only problem in your case is that has_cdefine_beep() returns false, just because neither the codec SSID nor the NID 0x1d pincfg indicates it as Realtek expects on Lenovo machines. The patch I provided is to ignore this Realtek SSID check but lets the function returning true as default for Lenovo machines. HOWEVER: if you add model=xxx option, it overrides this Lenovo default fixup but explicitly chooses another quirk. That's why I suggested to drop model option. Also, try to remove patch= option as well. If the beep mixer still doesn't apply, make sure that you're booting the patched kernel, e.g. by adding some printk call in patch_alc269(). If you're 100% sure that it's the correctly patched kernel, get alsa-info.sh output with it (run with --no-upload option) and attach the output to Bugzilla again for further analysis. Created attachment 232781 [details]
alsa info after patching
no love yet. if you could suggest some printk() outputs you would like to see I will add, recompile and display the output here. In patch_alc269 it would be nice to know what the result of case 0x10ec0269 is ... which codec was chosen. I don't recognize in case 0x20 the "subsystem_device == 0x21f3"
Do you have CONFIG_SND_HDA_INPUT_BEEP=y and CONFIG_SND_HDA_INPUT_BEEP_MODE=1 in your kernel config? Otherwise it won't appear. If you already had them, then it's really something wrong in patching kernel. The emulator shows that the patch adds the beep control. Double-check whether it's the patched kernel. In doubt, try the patch below instead of the previous one. It contains a few more debug prints in it, so you must see these "XXX" lines. Created attachment 232791 [details]
debug patch
(In reply to Takashi Iwai from comment #11) > Do you have CONFIG_SND_HDA_INPUT_BEEP=y and CONFIG_SND_HDA_INPUT_BEEP_MODE=1 > in your kernel config? Otherwise it won't appear. Of course: ..bash-4.3# cat /usr/src/linux/.config|grep -i beep ..CONFIG_INPUT_GPIO_BEEPER=m ..CONFIG_SND_HDA_INPUT_BEEP=y ..CONFIG_SND_HDA_INPUT_BEEP_MODE=1 I also have verbose sound debugging and verbose printk (for sound) enabled. > > If you already had them, then it's really something wrong in patching > kernel. The emulator shows that the patch adds the beep control. > > Double-check whether it's the patched kernel. In doubt, try the patch below > instead of the previous one. It contains a few more debug prints in it, so > you must see these "XXX" lines. We are talking about just a few lines of code. I can not use an automated patch function as our line numbers seem to differ. Remember I am building from 4.4.14 kernel. I added your few lines by copy past in the appropriate sections. e.g: static void alc_fixup_sku_ignore(struct hda_codec *codec, const struct hda_fixup *fix, int action) { struct alc_spec *spec = codec->spec; if (action == HDA_FIXUP_ACT_PRE_PROBE) { spec->cdefine.fixup = 1; spec->cdefine.sku_cfg = ALC_FIXUP_SKU_IGNORE; /* * YOUR CODE HERE */ codec_info(codec, "XXX alc_fixup_sku_ignore\n"); /* * END YOUR CODE */ } } It builds fine. I am not seeing any XXX.... in either dmesg or alsa-info. Again, I notice that codec->bus->pci->subsystem_device reports 0x22a for my setup and there are some checks (if statements or case) in patch_realtek.c for the subsystem_device that lead to different fixups. Perhaps my variant leads to a dead end solved! Compiled kernel with appropriate sound modules built-in (not as loadable modules) e.g. CONFIG_SND_HDA_INTEL=y. The Beep mixer control appeared in alsamixer. I had tried this solution before (compiling sound modules built in) but not after your patch. Your two line patch works and should be included in future kernel releases. Perhaps and update to the HD-Audio.txt file in Kernel Documentation suggesting compiling this way would be useful in the debugging section. Thank you Takashi for your assistance and for the helpful suggestions. Regards, Pat Created attachment 232921 [details]
alsa-info.sh output final working
For the record, final output from alsa-info.sh working with 2 line kernel patch
Good to hear that the patch works for you. The patch is merged now to sound.git tree targeted for 4.9 kernel. It's an open question whether this should be merged as a stable kernel fix. Since it touches other devices, I hesitate to merge it for 4.8-rc with stable for now... Maybe we can ask to merge to stable once after it's confirmed to work stable after 4.9 release. |