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