Bug 81561

Summary: Headphones detection don't work after first bool on Acer Aspire V5-573G
Product: Drivers Reporter: Stanislav (prodoomman)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: RESOLVED CODE_FIX    
Severity: normal CC: sl1pkn07, superquad.vortex2, tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: all, up to 3.16-rc7 Subsystem:
Regression: No Bisected commit-id:
Attachments: Full dmesg output
Alsa info after first boot (headphones detect don't work)
Alsa info after reboot (headphones detect works fine)
Fix patch
Alsa info after first boot (headphones detect don't work), fix patch has been applied
Alsa info after reboot (headphones detect works fine), fix patch has been applied
Patched file patch_realtek.c

Description Stanislav 2014-08-02 16:05:30 UTC
Created attachment 144911 [details]
Full dmesg output

When I power on my notebook Acer Aspire V5-573G with Realtec ALC282 soundcard I can't use headphones. When I plug on jack, headphones don't work. In dmesg I have message 'SKU not ready':

sound hdaudioC1D0: ALC282: SKU not ready 0x411111f0
sound hdaudioC1D0: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
sound hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
sound hdaudioC1D0:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
sound hdaudioC1D0:    mono: mono_out=0x0
sound hdaudioC1D0:    dig-out=0x1e/0x0
sound hdaudioC1D0:    inputs:
sound hdaudioC1D0:      Front Mic=0x19
sound hdaudioC1D0:      Rear Mic=0x18
sound hdaudioC1D0:      Line=0x1a

After reboot headphones works normal, dmesg doesn't have error message.

Bug is reprodusable in Debian Jessie, Fedora 20 and all other linux distributions. My current kernel is 3.16.0-031600rc7-generic from ubuntu kernel ppa.
Comment 1 Takashi Iwai 2014-08-04 11:31:46 UTC
"SKU not ready" is no error but just information that BIOS doesn't set the PCI/codec SSID as Realtek supposed.  You can safely ignore it.

The problem is, however, BIOS sets up only one pin for the speaker and nothing else.  When the headphone works after boot, BIOS resets the pins correctly at reboot.

Please take alsa-info.sh outputs on both the first (non-working) and the second (working) boots.  Run the script with --no-upload option, and attach the outputs to Bugzilla.
Comment 2 Stanislav 2014-08-05 02:27:12 UTC
Created attachment 145181 [details]
Alsa info after first boot (headphones detect don't work)
Comment 3 Stanislav 2014-08-05 02:27:47 UTC
Created attachment 145191 [details]
Alsa info after reboot (headphones detect works fine)
Comment 4 Takashi Iwai 2014-08-06 14:08:22 UTC
The pin table is completely different between and after reboot.  At the first boot, it contains:

NID 0x14: cfg 0x99131110: [Fixed] Speaker at Int ATAPI
NID 0x18: cfg 0x01a19050: [Jack] Mic at Ext Rear
NID 0x19: cfg 0x02a19080: [Jack] Mic at Ext Front
NID 0x1a: cfg 0x0181305f: [Jack] Line In at Ext Rear
NID 0x1e: cfg 0x01441170: [Jack] SPDIF Out at Ext Rear

while after the reboot, it becomes:

NID 0x12: cfg 0x90a60130: [Fixed] Mic at Int N/A
NID 0x14: cfg 0x90170110: [Fixed] Speaker at Int N/A
NID 0x21: cfg 0x0321101f: [Jack] HP Out at Ext Left

Are the latter pins correct?  That is, does your machine have only these three audio I/Os?  If so, I can cook up a fix patch.
Comment 5 Takashi Iwai 2014-08-06 14:18:06 UTC
Created attachment 145291 [details]
Fix patch

To be applied to the latest sound git tree
Comment 6 Stanislav 2014-08-07 10:20:45 UTC
My machine has speaker, internal microphone and combined (headphones+microphone) jack.
I will try to build kernel with your fix patch later.
Comment 7 Takashi Iwai 2014-08-07 11:35:50 UTC
The mic on the combo jack might be not working, I suppose, even with the state after reboot.  It's a different issue, so please open another bug report for tracking it.
Comment 8 Stanislav 2014-08-26 15:48:46 UTC
I apply fix patch to the linux kernel 3.16.1, but nothing changed. Headphones detection still don't work on first boot.
Comment 9 Stanislav 2014-08-26 15:49:44 UTC
Created attachment 148341 [details]
Alsa info after first boot (headphones detect don't work), fix patch has been applied
Comment 10 Stanislav 2014-08-26 15:50:11 UTC
Created attachment 148351 [details]
Alsa info after reboot (headphones detect works fine), fix patch has been applied
Comment 11 Takashi Iwai 2014-08-26 15:57:36 UTC
Are you sure that you're booting the patched kernel?  Try to put some printk to see whether it's really a patched one.

When the patch is properly applied and the device (1024:079b) is detected, it should appear in the difference of pins.  The patched kernel should show some contents in driver_pin_configs in sysfs (found in alsa-info.sh output).
Comment 12 Stanislav 2014-08-26 17:18:39 UTC
Created attachment 148371 [details]
Patched file patch_realtek.c

I add printk to sources and found that I really boot modified kernel:
$ dmesg| grep 573g
Hello from patched kernel (v5 573g snd_hda headphones patch).

May be I not correctly apply patch to sources?
Comment 13 Takashi Iwai 2014-08-26 17:55:36 UTC
The patch was applied incorrectly.  The addition of SND_PCI_QUIRK() must be before SND_PCI_QUIRK(0x1025, "Acer Aspire"....)   Otherwise the vendor quirk is taken and the rest is ignored.
Comment 14 Stanislav 2014-08-26 19:19:15 UTC
My mistake.
Your patch working perfectly. Thank you!
Comment 15 Takashi Iwai 2014-08-27 06:25:53 UTC
OK, the patch is merged, will be included in the next pull request to 3.17-rc kernel.  Thanks for testing.
Comment 16 Gustavo Alvarez Lopez 2014-09-25 21:56:36 UTC
Hi

have this issue in a Mobo Gigabyte GA-EX58-UD5 (older) and EVGA Classified SR-2 (actual)

since kernel 3.14 (3.13 works)

https://bugs.archlinux.org/task/40199

both have ALC889 sound card

all jack inertion is detected by acpi_listen except front jack headphones (green)

in a SR-2 dmesg say

http://sl1pkn07.wtf/paste/view/c8b7825b

relevant:

[    5.604873] sound hdaudioC0D2: ignore pin 0x1b with mismatching assoc# 0x2 vs 0x1

and

[    5.604963] sound hdaudioC0D2:    inputs:
[    5.604966] sound hdaudioC0D2:      Front Mic=0x19
[    5.604969] sound hdaudioC0D2:      Rear Mic=0x18
[    5.604971] sound hdaudioC0D2:      Line=0x1a
[    5.604973] sound hdaudioC0D2:    dig-in=0x1f

the pinheader is intalled correctly in mobo

greetings
Comment 17 Raymond 2014-09-27 10:02:26 UTC
post output of alsa-info.sh


seem your BIOS setup node 0x1b your front panel HP as Line Out

and the auto parser check def association is different from rear panel line out

you need to retask it as HP instead of Line Out


04873] sound hdaudioC0D2: ignore pin 0x1b with mismatching assoc# 0x2 vs 0x1

[    5.604952] sound hdaudioC0D2: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line

[    5.604954] sound hdaudioC0D2:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)

[    5.604957] sound hdaudioC0D2:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)

[    5.604959] sound hdaudioC0D2:    mono: mono_out=0x0

[    5.604961] sound hdaudioC0D2:    dig-out=0x1e/0x0

[    5.604963] sound hdaudioC0D2:    inputs:

[    5.604966] sound hdaudioC0D2:      Front Mic=0x19

[    5.604969] sound hdaudioC0D2:      Rear Mic=0x18

[    5.604971] sound hdaudioC0D2:      Line=0x1a

[    5.604973] sound hdaudioC0D2:    dig-in=0x1f
Comment 18 Gustavo Alvarez Lopez 2014-09-27 10:58:01 UTC
full dmesg gigabyte GA-EX58-UD5
http://sl1pkn07.wtf/paste/view/a6f7feb4 (from arch bug report)

alsa-log.sh in EVGA SR-2
http://sl1pkn07.wtf/paste/view/613b967b

yes, with hdajackretask and override the output 0x1b to HP fix the headphone conection (stop sound in rear output (connected to 5.1 speakers))

but in 3.13 that's work out of the box, and start failed in 3.14

seems like a regresion, or fixed older bug, depend of the point of view

greetings