[alsa-devel] [Regression] With the new 2.6.33 when I plug headphones, the speaker doen't get off anymore
Hi,
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Thx a lot, Best regards Guillaume
Dear Guillaume,
Am Freitag, den 26.02.2010, 10:03 +0100 schrieb giggzounet:
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I find it good that you attached the files, so I could produce a diff easily. Besides some additional control elements and names the following difference shows up.
$ diff -u alsa-info_2.6.32.9.log alsa-info_2.6.33.log --- alsa-info_2.6.32.9.log 2010-02-26 10:14:01.000000000 +0100 +++ alsa-info_2.6.33.log 2010-02-26 10:14:06.000000000 +0100 @@ -3,7 +3,7 @@
[…]
@@ -85,11 +85,12 @@
!!Module: snd_hda_intel bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1 + beep_mode : 1,1,1,1,1,1,1,1 enable : Y,Y,Y,Y,Y,Y,Y,Y - enable_msi : 0 - id : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL> + enable_msi : -1 + id : (null),(null),(null),(null),(null),(null),(null),(null) index : 0,-1,-1,-1,-1,-1,-1,-1 - model : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL> + model : (null),(null),(null),(null),(null),(null),(null),(null) position_fix : 0,0,0,0,0,0,0,0 power_save : 5 power_save_controller : N […]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Please always provide a link I can just click on and try to put as much reference to already existing posts as possible. This refers to the post on Debian-eeepc-devel [2].
Thanks,
Paul
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... [2] http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/00...
Paul Menzel a écrit :
Dear Guillaume,
Hi,
Thx for your quick reply!
Am Freitag, den 26.02.2010, 10:03 +0100 schrieb giggzounet:
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I find it good that you attached the files, so I could produce a diff easily. Besides some additional control elements and names the following difference shows up.
$ diff -u alsa-info_2.6.32.9.log alsa-info_2.6.33.log --- alsa-info_2.6.32.9.log 2010-02-26 10:14:01.000000000 +0100 +++ alsa-info_2.6.33.log 2010-02-26 10:14:06.000000000 +0100 @@ -3,7 +3,7 @@ […] @@ -85,11 +85,12 @@ !!Module: snd_hda_intel bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1 + beep_mode : 1,1,1,1,1,1,1,1 enable : Y,Y,Y,Y,Y,Y,Y,Y - enable_msi : 0 - id : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL> + enable_msi : -1 + id : (null),(null),(null),(null),(null),(null),(null),(null) index : 0,-1,-1,-1,-1,-1,-1,-1 - model : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL> + model : (null),(null),(null),(null),(null),(null),(null),(null) position_fix : 0,0,0,0,0,0,0,0 power_save : 5 power_save_controller : N […]I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]
I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I compile the kernel myself. So perhaps I forget something...I have uploaded on the kernel bugzilla (http://bugzilla.kernel.org/show_bug.cgi?id=15399) the 2 config files of my custom kernels : one for the 2.6.32.9 which works and one for the 2.6.33 which doesn't work.
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Please always provide a link I can just click on and try to put as much reference to already existing posts as possible. This refers to the post on Debian-eeepc-devel [2].
the bug on kernel bugzilla : http://bugzilla.kernel.org/show_bug.cgi?id=15399
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... [2] http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/00...
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
Am Freitag, den 26.02.2010, 12:15 +0100 schrieb giggzounet:
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
That’s unfortunate. It would have been nice if this had fixed it.
I CC Takashi, since he is the author of [1]. Maybe he can tell us if it is related.
The only relevant(?) difference there is the following.
$ diff -u alsa-info_2.6.32.9.log alsa-info_2.6.33_enable_msi.log […] @@ -85,11 +85,12 @@
!!Module: snd_hda_intel bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1 + beep_mode : 1,1,1,1,1,1,1,1 […]
The only other thing I can think of is, that you go trough the commit log yourself and try to figure out what changed regarding to your chipset and CODEC.
And last not least you could try DebPkg:libasound2 from unstable and see if this changes anything. Although I guess it will not.
Thanks,
Paul
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...
Paul Menzel a écrit :
Am Freitag, den 26.02.2010, 12:15 +0100 schrieb giggzounet:
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
That’s unfortunate. It would have been nice if this had fixed it.
I CC Takashi, since he is the author of [1]. Maybe he can tell us if it is related.
The only relevant(?) difference there is the following.
$ diff -u alsa-info_2.6.32.9.log alsa-info_2.6.33_enable_msi.log […] @@ -85,11 +85,12 @@ !!Module: snd_hda_intel bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1 + beep_mode : 1,1,1,1,1,1,1,1 […]The only other thing I can think of is, that you go trough the commit log yourself and try to figure out what changed regarding to your chipset and CODEC.
And last not least you could try DebPkg:libasound2 from unstable and see if this changes anything. Although I guess it will not.
I'm using the libasound2 from lenny-backport version 1.0.21. Also it is not very far from the one in unstable (1.0.22).
Thanks,
Paul
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...
Paul Menzel a écrit :
Am Freitag, den 26.02.2010, 12:15 +0100 schrieb giggzounet:
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
That’s unfortunate. It would have been nice if this had fixed it.
I have take a look to the history of changes of hda_intel.f and found that : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
in the source I'm seeing a blacklist : /* * white/black-list for enable_msi */ static struct snd_pci_quirk msi_black_list[] __devinitdata = { SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */ SND_PCI_QUIRK(0x1043, 0x81f6, "ASUS", 0), /* nvidia */ {} };
And on my eeepc 1201n there is lot's of nvidia things...How can I know if I'm on this blacklist or not ? ...sorry, I don't have a lot of knowledge in C. But this could be explain why msi is not enabled by default...
Best regards, Guillaume
Am Freitag, den 26.02.2010, 15:00 +0100 schrieb giggzounet:
Paul Menzel a écrit :
Am Freitag, den 26.02.2010, 12:15 +0100 schrieb giggzounet:
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
That’s unfortunate. It would have been nice if this had fixed it.
I have take a look to the history of changes of hda_intel.f and found that : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
in the source I'm seeing a blacklist : /*
- white/black-list for enable_msi
*/ static struct snd_pci_quirk msi_black_list[] __devinitdata = { SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */ SND_PCI_QUIRK(0x1043, 0x81f6, "ASUS", 0), /* nvidia */ {} };
And on my eeepc 1201n there is lot's of nvidia things...How can I know if I'm on this blacklist or not ? ...sorry, I don't have a lot of knowledge in C. But this could be explain why msi is not enabled by default...
Just to make it clear. I am also stabbing in the dark here and do not know what those options actually do. I just saw the difference in the outputs of `alsa-info.sh`. Maybe you can try to load `snd-hda-intel` with `enable_msi=1` to enable it explicitly and try it? But I emphasize again that this MSI issue might not be related to your problem at all.
Anyway, looking at the output of `alsa-info.sh` which executes I think `lspci -vnn` we find your IDs. (I just looked through the file and “grepped” it just to include it here.
$ grep "PCI Vendor" -A4 alsa-info_2.6.33.log !!Advanced information - PCI Vendor/Device/Susbsystem ID's !!--------------------------------------------------------
00:08.0 0403: 10de:0ac0 (rev b1) Subsystem: 1043:83ce
So those quirks you listed do not apply to your system. Searching for your device ID’s in the tree reveals the following.
sound-2.6/sound/pci/hda$ grep -Ri 83ce * patch_realtek.c: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC),
`ALC269_DMIC` turns up in `patch_realtek.c` in the following places.
sound-2.6/sound/pci/hda$ more patch_realtek.c /* * configuration and preset */ static const char *alc269_models[ALC269_MODEL_LAST] = { [ALC269_BASIC] = "basic", [ALC269_QUANTA_FL1] = "quanta", [ALC269_AMIC] = "laptop-amic", [ALC269_DMIC] = "laptop-dmic", [ALC269_FUJITSU] = "fujitsu", [ALC269_LIFEBOOK] = "lifebook", [ALC269_AUTO] = "auto", }; […] [ALC269_DMIC] = { .mixers = { alc269_laptop_mixer }, .cap_mixer = alc269_laptop_digital_capture_mixer, .init_verbs = { alc269_init_verbs, alc269_laptop_dmic_init_verbs }, .num_dacs = ARRAY_SIZE(alc269_dac_nids), .dac_nids = alc269_dac_nids, .hp_nid = 0x03, .num_channel_mode = ARRAY_SIZE(alc269_modes), .channel_mode = alc269_modes, .unsol_event = alc269_laptop_unsol_event, .setup = alc269_laptop_dmic_setup, .init_hook = alc269_laptop_inithook, },
But I have not clue what that all does. I do not know if and when Takashi or some other dev will have time to answer, but until then you could ask on IRC or try to figure out if something changed there or in the function it calls. I think `git annotate` comes to your rescue here.
Sorry, that I cannot help you further. Thanks,
Paul
Paul Menzel a écrit :
Am Freitag, den 26.02.2010, 15:00 +0100 schrieb giggzounet:
Paul Menzel a écrit :
Am Freitag, den 26.02.2010, 12:15 +0100 schrieb giggzounet:
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
That’s unfortunate. It would have been nice if this had fixed it.
I have take a look to the history of changes of hda_intel.f and found that : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
in the source I'm seeing a blacklist : /*
- white/black-list for enable_msi
*/ static struct snd_pci_quirk msi_black_list[] __devinitdata = { SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */ SND_PCI_QUIRK(0x1043, 0x81f6, "ASUS", 0), /* nvidia */ {} };
And on my eeepc 1201n there is lot's of nvidia things...How can I know if I'm on this blacklist or not ? ...sorry, I don't have a lot of knowledge in C. But this could be explain why msi is not enabled by default...
Just to make it clear. I am also stabbing in the dark here and do not know what those options actually do. I just saw the difference in the outputs of `alsa-info.sh`. Maybe you can try to load `snd-hda-intel` with `enable_msi=1` to enable it explicitly and try it? But I emphasize again that this MSI issue might not be related to your problem at all.
Anyway, looking at the output of `alsa-info.sh` which executes I think `lspci -vnn` we find your IDs. (I just looked through the file and “grepped” it just to include it here.
$ grep "PCI Vendor" -A4 alsa-info_2.6.33.log !!Advanced information - PCI Vendor/Device/Susbsystem ID's !!-------------------------------------------------------- 00:08.0 0403: 10de:0ac0 (rev b1) Subsystem: 1043:83ceSo those quirks you listed do not apply to your system. Searching for your device ID’s in the tree reveals the following.
sound-2.6/sound/pci/hda$ grep -Ri 83ce * patch_realtek.c: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC),`ALC269_DMIC` turns up in `patch_realtek.c` in the following places.
sound-2.6/sound/pci/hda$ more patch_realtek.c /* * configuration and preset */ static const char *alc269_models[ALC269_MODEL_LAST] = { [ALC269_BASIC] = "basic", [ALC269_QUANTA_FL1] = "quanta", [ALC269_AMIC] = "laptop-amic", [ALC269_DMIC] = "laptop-dmic", [ALC269_FUJITSU] = "fujitsu", [ALC269_LIFEBOOK] = "lifebook", [ALC269_AUTO] = "auto", }; […] [ALC269_DMIC] = { .mixers = { alc269_laptop_mixer }, .cap_mixer = alc269_laptop_digital_capture_mixer, .init_verbs = { alc269_init_verbs, alc269_laptop_dmic_init_verbs }, .num_dacs = ARRAY_SIZE(alc269_dac_nids), .dac_nids = alc269_dac_nids, .hp_nid = 0x03, .num_channel_mode = ARRAY_SIZE(alc269_modes), .channel_mode = alc269_modes, .unsol_event = alc269_laptop_unsol_event, .setup = alc269_laptop_dmic_setup, .init_hook = alc269_laptop_inithook, },But I have not clue what that all does. I do not know if and when Takashi or some other dev will have time to answer, but until then you could ask on IRC or try to figure out if something changed there or in the function it calls. I think `git annotate` comes to your rescue here.
THx for all these infos. that helps me to start!
Sorry, that I cannot help you further. Thanks,
no problem! You already have helped me a lot! I will wait for the developper. And take a look to the source.
Bye bye Guillaume
giggzounet a écrit :
[snip]
I do not know why enable_msi is set to »-1« and not one since it should be enabled by default now [1]. Could you try to load the sound module with `enable_msi` set to `0` and report back your findings, please.
$ sudo modinfo snd-hda-intel […] parm: enable_msi:Enable Message Signaled Interrupt (MSI) (int) […]I have modified /etc/modprobe.d/sound with : snd-hda-intel index=0 enable_msi=0
I attach the log of alsa-info.
I have forgotten to say that the problem is always here with enable_msi=0
[snip]
I have tested with enable_msi=1. I always have the problem with the headphone and speakers. But I don't know why I don't get enable_msi=1 automaticly, because it seems to work fine.
giggzounet a écrit :
Hi,
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Following the advice of Paul Menzel I did a "diff" of the sources of the 2.6.32.9 kernel and of the 2.6.33. In patch_realtek.c, we see that there is an new snd_hda_jack_detect funtion with 2 arguments. I have noticed that the second argument is "normaly" the second argument of snd_hda_codec_read. In the alc269_speaker_automute function there is this new snd_hda_jack_detect function, but the second argument is "nid". But in the old alc269_speaker_automute of the 2.6.32.9 the second argument of snd_hda_codec_read is 0x15. So I think there is perhaps a bug here...But I hesitate to modify the source...so I'm waiting the anwser of the dev.
--- patch_realtek.c 2010-02-27 14:58:06.000000000 +0100 +++ patch_realtek_modif.c 2010-02-27 14:58:54.000000000 +0100 @@ -13381,7 +13381,7 @@ unsigned int present; unsigned char bits;
- present = snd_hda_jack_detect(codec, nid); + present = snd_hda_jack_detect(codec, 0x15); bits = present ? AMP_IN_MUTE(0) : 0; snd_hda_codec_amp_stereo(codec, 0x0c, HDA_INPUT, 0, AMP_IN_MUTE(0), bits);
Best regards, Guillaume
giggz a écrit :
giggzounet a écrit :
Hi,
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Following the advice of Paul Menzel I did a "diff" of the sources of the 2.6.32.9 kernel and of the 2.6.33. In patch_realtek.c, we see that there is an new snd_hda_jack_detect funtion with 2 arguments. I have noticed that the second argument is "normaly" the second argument of snd_hda_codec_read. In the alc269_speaker_automute function there is this new snd_hda_jack_detect function, but the second argument is "nid". But in the old alc269_speaker_automute of the 2.6.32.9 the second argument of snd_hda_codec_read is 0x15. So I think there is perhaps a bug here...But I hesitate to modify the source...so I'm waiting the anwser of the dev.
--- patch_realtek.c 2010-02-27 14:58:06.000000000 +0100 +++ patch_realtek_modif.c 2010-02-27 14:58:54.000000000 +0100 @@ -13381,7 +13381,7 @@ unsigned int present; unsigned char bits;
- present = snd_hda_jack_detect(codec, nid);
- present = snd_hda_jack_detect(codec, 0x15); bits = present ? AMP_IN_MUTE(0) : 0; snd_hda_codec_amp_stereo(codec, 0x0c, HDA_INPUT, 0, AMP_IN_MUTE(0), bits);
I tested it. And with this modif in the kernel, after recompilation and reboot, my problem is headphones and speaker is gone.
Best regards, Guillaume
At Sun, 28 Feb 2010 15:29:25 +0100, giggz wrote:
giggz a écrit :
giggzounet a écrit :
Hi,
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Following the advice of Paul Menzel I did a "diff" of the sources of the 2.6.32.9 kernel and of the 2.6.33. In patch_realtek.c, we see that there is an new snd_hda_jack_detect funtion with 2 arguments. I have noticed that the second argument is "normaly" the second argument of snd_hda_codec_read. In the alc269_speaker_automute function there is this new snd_hda_jack_detect function, but the second argument is "nid". But in the old alc269_speaker_automute of the 2.6.32.9 the second argument of snd_hda_codec_read is 0x15. So I think there is perhaps a bug here...But I hesitate to modify the source...so I'm waiting the anwser of the dev.
--- patch_realtek.c 2010-02-27 14:58:06.000000000 +0100 +++ patch_realtek_modif.c 2010-02-27 14:58:54.000000000 +0100 @@ -13381,7 +13381,7 @@ unsigned int present; unsigned char bits;
- present = snd_hda_jack_detect(codec, nid);
- present = snd_hda_jack_detect(codec, 0x15); bits = present ? AMP_IN_MUTE(0) : 0; snd_hda_codec_amp_stereo(codec, 0x0c, HDA_INPUT, 0, AMP_IN_MUTE(0), bits);
I tested it. And with this modif in the kernel, after recompilation and reboot, my problem is headphones and speaker is gone.
It implies that the setup of the headphone pin is wrong. This doesn't mean a bug of the driver, though. It might have uncovered the BIOS bug.
Could you provide alsa-info.sh without your patch to check the setup?
thanks,
Takashi
Takashi Iwai a écrit :
At Sun, 28 Feb 2010 15:29:25 +0100, giggz wrote:
giggz a écrit :
giggzounet a écrit :
Hi,
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Following the advice of Paul Menzel I did a "diff" of the sources of the 2.6.32.9 kernel and of the 2.6.33. In patch_realtek.c, we see that there is an new snd_hda_jack_detect funtion with 2 arguments. I have noticed that the second argument is "normaly" the second argument of snd_hda_codec_read. In the alc269_speaker_automute function there is this new snd_hda_jack_detect function, but the second argument is "nid". But in the old alc269_speaker_automute of the 2.6.32.9 the second argument of snd_hda_codec_read is 0x15. So I think there is perhaps a bug here...But I hesitate to modify the source...so I'm waiting the anwser of the dev.
--- patch_realtek.c 2010-02-27 14:58:06.000000000 +0100 +++ patch_realtek_modif.c 2010-02-27 14:58:54.000000000 +0100 @@ -13381,7 +13381,7 @@ unsigned int present; unsigned char bits;
- present = snd_hda_jack_detect(codec, nid);
- present = snd_hda_jack_detect(codec, 0x15); bits = present ? AMP_IN_MUTE(0) : 0; snd_hda_codec_amp_stereo(codec, 0x0c, HDA_INPUT, 0, AMP_IN_MUTE(0), bits);
I tested it. And with this modif in the kernel, after recompilation and reboot, my problem is headphones and speaker is gone.
It implies that the setup of the headphone pin is wrong. This doesn't mean a bug of the driver, though. It might have uncovered the BIOS bug.
ok. I don't have any knowledge in C or in bios...so you're problably right :)
but it seems strange that for all the new line with snd_hda_jack_detect the second argument is always the second argument of snd_hda_codec_read except for the alc269.
Could you provide alsa-info.sh without your patch to check the setup?
In attachment of the first post on alsa-devel or on the kernel bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=15399, there are the output of alsa-info.sh with the 2.6.32.9 (no problem) and the output of alsa-info.sh with the 2.6.33 without any patch (problem occurs).
Do you need another outputs ?
Thx for your driver! Best regards, Guillaume
Takashi Iwai a écrit :
At Sun, 28 Feb 2010 15:29:25 +0100, giggz wrote:
giggz a écrit :
giggzounet a écrit :
Hi,
I have installed debian stable lenny + backports on an eeepc 1201n. With the 2.6.30 or 2.6.32 from lenny-backport I don't have problem with sound : when I plug the headphones, speakers get off.
I have tested with 2.6.33 and when I plug headphones, speakers don't get off anymore. so I have sound in headphones and speakers.
22:42 giggz@baal ~ % cat /proc/asound/card0/codec#* | grep Codec Codec: Realtek ALC269 Codec: Nvidia MCP7A HDMI
I attach the output of alsa-info with the 2.6.32.9 and the 2.6.33 (I'm in a Uni Campus and it's quite difficult to have internet on a external laptop...so I attach them at this mail and I don't upload them on pastbin).
I have opened a bug on the kernel bugzilla (bug 15399). Should I provide anything more ?
Following the advice of Paul Menzel I did a "diff" of the sources of the 2.6.32.9 kernel and of the 2.6.33. In patch_realtek.c, we see that there is an new snd_hda_jack_detect funtion with 2 arguments. I have noticed that the second argument is "normaly" the second argument of snd_hda_codec_read. In the alc269_speaker_automute function there is this new snd_hda_jack_detect function, but the second argument is "nid". But in the old alc269_speaker_automute of the 2.6.32.9 the second argument of snd_hda_codec_read is 0x15. So I think there is perhaps a bug here...But I hesitate to modify the source...so I'm waiting the anwser of the dev.
--- patch_realtek.c 2010-02-27 14:58:06.000000000 +0100 +++ patch_realtek_modif.c 2010-02-27 14:58:54.000000000 +0100 @@ -13381,7 +13381,7 @@ unsigned int present; unsigned char bits;
- present = snd_hda_jack_detect(codec, nid);
- present = snd_hda_jack_detect(codec, 0x15); bits = present ? AMP_IN_MUTE(0) : 0; snd_hda_codec_amp_stereo(codec, 0x0c, HDA_INPUT, 0, AMP_IN_MUTE(0), bits);
I tested it. And with this modif in the kernel, after recompilation and reboot, my problem is headphones and speaker is gone.
It implies that the setup of the headphone pin is wrong. This doesn't mean a bug of the driver, though. It might have uncovered the BIOS bug.
Could you provide alsa-info.sh without your patch to check the setup?
With the model=auto option, the problem of the speaker automute disappears. I attach the alsa-info.sh with this option.
Best regards, GiGGz
participants (4)
-
giggz -
giggzounet
-
Paul Menzel -
Takashi Iwai