Bug 156311 - No PC speaker (Beep, system bell, pcspkr) when snd_hda_intel is loaded
Summary: No PC speaker (Beep, system bell, pcspkr) when snd_hda_intel is loaded
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 low
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-08 04:58 UTC by radiotubes
Modified: 2016-09-09 18:40 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.4.14
Subsystem:
Regression: No
Bisected commit-id:


Attachments
output from alsa-info.sh -non working configuration -- note "Node 0xb" settings (31.25 KB, text/plain)
2016-09-08 04:58 UTC, radiotubes
Details
pythton scrip to edit snd_hda-intel + realtec codec config. (1.05 KB, text/x-python)
2016-09-08 05:08 UTC, radiotubes
Details
Fix patch (1.74 KB, patch)
2016-09-08 10:21 UTC, Takashi Iwai
Details | Diff
ALC268 beep mixer ctl (731 bytes, text/plain)
2016-09-08 21:53 UTC, radiotubes
Details
alsa info after patching (31.42 KB, text/plain)
2016-09-09 01:26 UTC, radiotubes
Details
debug patch (1004 bytes, patch)
2016-09-09 06:44 UTC, Takashi Iwai
Details | Diff
alsa-info.sh output final working (31.01 KB, text/plain)
2016-09-09 18:02 UTC, radiotubes
Details

Description radiotubes 2016-09-08 04:58:33 UTC
Created attachment 232581 [details]
output from alsa-info.sh -non working configuration -- note "Node 0xb" settings

No system bell with snd_hda_intel loaded.  This is similar to this bug:  https://bugzilla.kernel.org/show_bug.cgi?id=121841.  That bug was marked as Resolved, however I have the same problem with similar hardware and was able to solve it. Mr. Takashi stated in the previous bug report that the Realtek doesn't have a digital beep widget, however this is incorrect.  Realtek ALC269 has a digital beep widget as well as the ALC283.  It is easily verifiable from the chip data sheet available online. Anyhow I was able to concurrently activate the pc speaker / system bell concurrently with snd_hda_intel by using the hda-analyzer script included in the alsa tools package.  

The attachment is the output of alsa-info.sh from the non working configuration.

Here is the difference for Node 0x0b in the working configuration:

..Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
..  Control: name="Mic Playback Volume", index=0, device=0
..    ControlAmp: chs=3, dir=In, idx=0, ofs=0
..  Control: name="Mic Playback Switch", index=0, device=0
..    ControlAmp: chs=3, dir=In, idx=0, ofs=0
..  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
..  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x0f 0x0f]
..  Connection: 5
..     0x18 0x19 0x1a 0x1b 0x1d
Comment 1 radiotubes 2016-09-08 05:08:12 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.
Comment 2 Takashi Iwai 2016-09-08 07:36:38 UTC
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...
Comment 3 Takashi Iwai 2016-09-08 10:21:13 UTC
Or try the patch below.  It should fix the issue generically on Lenovo machines.
Comment 4 Takashi Iwai 2016-09-08 10:21:56 UTC
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.
Comment 5 radiotubes 2016-09-08 15:13:08 UTC
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.
Comment 6 Takashi Iwai 2016-09-08 15:59:41 UTC
(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.
Comment 7 radiotubes 2016-09-08 21:53:13 UTC
Created attachment 232731 [details]
ALC268 beep mixer ctl
Comment 8 radiotubes 2016-09-08 21:53:33 UTC
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.
Comment 9 Takashi Iwai 2016-09-08 22:20:17 UTC
(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.
Comment 10 radiotubes 2016-09-09 01:26:25 UTC
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"
Comment 11 Takashi Iwai 2016-09-09 06:44:31 UTC
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.
Comment 12 Takashi Iwai 2016-09-09 06:44:56 UTC
Created attachment 232791 [details]
debug patch
Comment 13 radiotubes 2016-09-09 14:13:51 UTC
(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
Comment 14 radiotubes 2016-09-09 17:14:07 UTC
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
Comment 15 radiotubes 2016-09-09 18:02:58 UTC
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
Comment 16 Takashi Iwai 2016-09-09 18:40:53 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.