[alsa-devel] No sound from internal speaker on 2013 Macbook Air 6, 1
Hey all, I'm trying to get sound working on my new mid 2013 Macbook Air 6,1. Sound works via the headphone jack, but I haven't managed to get the internal speaker to work. I've checked all the controls in the mixer, tried a few different mac related model= options to snd-hda-intel and even tried tweaking things with hda_analyzer to no avail. I've uninstalled pulseaudio (for now) to get rid of it's ALSA hook, but had the same result both with and without it. I'm running on a 3.11-rc6+ built today (had a few other fixes to make for this machine) - I didn't bother including the hda i915 driver as I don't need sound via the display port, but the hda driver does print a warning about that missing module. The speaker wasn't working on the 3.10 kernel from Debian either which included that module. Any help would be appreciated - I've attached my alsa-info output taken after a reboot. Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
I'm trying to get sound working on my new mid 2013 Macbook Air 6,1.
Sound works via the headphone jack, but I haven't managed to get the internal speaker to work.
I've checked all the controls in the mixer, tried a few different mac related model= options to snd-hda-intel and even tried tweaking things with hda_analyzer to no avail.
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documenta... have you try those gpio ? or specify hints primary_hp = false it is strange that driver select amp at pin complex of headphone as headphone volume control instead of amp at audio output ( the number of step and dB range of headphone and speaker is different ) you may need to change the logic of look_for_out_vol_nid() in hda_generic.c you may need cs4208 datasheet if the codec need vendor coefff why virtual master did not warn when the dB range and number of step in slaves controls are different ? state.PCH { control.1 { iface MIXER name 'Headphone Playback Volume' value.0 66 value.1 66 comment { access 'read write' type INTEGER count 2 range '0 - 66' dbmin -6600 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.3 { iface MIXER name 'Speaker Playback Volume' value.0 127 value.1 127 comment { access 'read write' type INTEGER count 2 range '0 - 127' dbmin -6350 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.10 { iface MIXER name 'Master Playback Volume' value 46 comment { access 'read write' type INTEGER count 1 range '0 - 66' dbmin -6600 dbmax 0 dbvalue.0 -2000 } }
Hi Raymond, On 26 August 2013 11:55, Raymond Yau <superquad.vortex2@gmail.com> wrote:
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documenta...
have you try those gpio ?
Thanks for the pointer - I finally got around to trying this (it's not my primary box) and was able to get the speaker to work by enabling GPIO 0 as an output with data=1 (i.e. I selected out-dir, enable and data in hda-analyzer). I noticed that the GPIO settings would clear when I stopped playing sound though, so I currently have to run the python script generated by hda-analyzer every time I want to play a sound through the speaker. I also noticed that I had to manually set data=0 to turn the speaker off if I plugged in the headphones. What is the next step in fixing this properly? I've been meaning to look through the hda code to figure out how these kind of quirks are supposed to be handled, but haven't got around to that yet.
or specify hints primary_hp = false
That did nothing by itself, though come to think of it I didn't try it in combination with the GPIO settings.
it is strange that driver select amp at pin complex of headphone as headphone volume control instead of amp at audio output ( the number of step and dB range of headphone and speaker is different )
you may need to change the logic of look_for_out_vol_nid() in hda_generic.c
Hmm, the volume control seemed to be working for me with both speakers & headphones, but I didn't check which control it was actually changing.
you may need cs4208 datasheet if the codec need vendor coefff
why virtual master did not warn when the dB range and number of step in slaves controls are different ?
Is that something I need to be concerned about? Where should that warning have appeared? Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
At Mon, 9 Sep 2013 18:01:41 +1000, Ian Munsie wrote:
Hi Raymond,
On 26 August 2013 11:55, Raymond Yau <superquad.vortex2@gmail.com> wrote:
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documenta...
have you try those gpio ?
Thanks for the pointer - I finally got around to trying this (it's not my primary box) and was able to get the speaker to work by enabling GPIO 0 as an output with data=1 (i.e. I selected out-dir, enable and data in hda-analyzer).
I noticed that the GPIO settings would clear when I stopped playing sound though, so I currently have to run the python script generated by hda-analyzer every time I want to play a sound through the speaker. I also noticed that I had to manually set data=0 to turn the speaker off if I plugged in the headphones.
What is the next step in fixing this properly? I've been meaning to look through the hda code to figure out how these kind of quirks are supposed to be handled, but haven't got around to that yet.
Please give alsa-info.sh output, then we'll provide some trivial test patches. At best, run alsa-info.sh with --no-upload option and attach the output.
or specify hints primary_hp = false
That did nothing by itself, though come to think of it I didn't try it in combination with the GPIO settings.
it is strange that driver select amp at pin complex of headphone as headphone volume control instead of amp at audio output ( the number of step and dB range of headphone and speaker is different )
you may need to change the logic of look_for_out_vol_nid() in hda_generic.c
Hmm, the volume control seemed to be working for me with both speakers & headphones, but I didn't check which control it was actually changing.
you may need cs4208 datasheet if the codec need vendor coefff
why virtual master did not warn when the dB range and number of step in slaves controls are different ?
Is that something I need to be concerned about? Where should that warning have appeared?
If GPIO does fix the issue, that's all what we need. Takashi
Please give alsa-info.sh output, then we'll provide some trivial test patches. At best, run alsa-info.sh with --no-upload option and attach the output.
I included that in my original mail: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-August/065742.html http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20130824/fe... Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
At Mon, 9 Sep 2013 19:44:13 +1000, Ian Munsie wrote:
Please give alsa-info.sh output, then we'll provide some trivial test patches. At best, run alsa-info.sh with --no-upload option and attach the output.
I included that in my original mail:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-August/065742.html http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20130824/fe...
OK, then try the patch below. Takashi --- diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index cccaf9c..b524f89 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -169,7 +169,7 @@ static void cs_automute(struct hda_codec *codec) snd_hda_gen_update_outputs(codec); - if (spec->gpio_eapd_hp) { + if (spec->gpio_eapd_hp || spec->gpio_eapd_speaker) { spec->gpio_data = spec->gen.hp_jack_present ? spec->gpio_eapd_hp : spec->gpio_eapd_speaker; snd_hda_codec_write(codec, 0x01, 0, @@ -291,10 +291,11 @@ static int cs_init(struct hda_codec *codec) { struct cs_spec *spec = codec->spec; - /* init_verb sequence for C0/C1/C2 errata*/ - snd_hda_sequence_write(codec, cs_errata_init_verbs); - - snd_hda_sequence_write(codec, cs_coef_init_verbs); + if (spec->vendor_nid == CS420X_VENDOR_NID) { + /* init_verb sequence for C0/C1/C2 errata*/ + snd_hda_sequence_write(codec, cs_errata_init_verbs); + snd_hda_sequence_write(codec, cs_coef_init_verbs); + } snd_hda_gen_init(codec); @@ -307,8 +308,10 @@ static int cs_init(struct hda_codec *codec) spec->gpio_data); } - init_input_coef(codec); - init_digital_coef(codec); + if (spec->vendor_nid == CS420X_VENDOR_NID) { + init_input_coef(codec); + init_digital_coef(codec); + } return 0; } @@ -552,6 +555,76 @@ static int patch_cs420x(struct hda_codec *codec) } /* + * CS4208 support: + * Its layout is no longer compatible with CS4206/CS4207, and the generic + * parser seems working fairly well, except for trivial fixups. + */ +enum { + CS4208_GPIO0, +}; + +static const struct hda_model_fixup cs4208_models[] = { + { .id = CS4208_GPIO0, .name = "gpio0" }, + {} +}; + +static const struct snd_pci_quirk cs4208_fixup_tbl[] = { + /* codec SSID */ + SND_PCI_QUIRK(0x106b, 0x7100, "MacBookPro 6,1", CS4208_GPIO0), + SND_PCI_QUIRK(0x106b, 0x7200, "MacBookPro 6,2", CS4208_GPIO0), + {} /* terminator */ +}; + +static void cs4208_fixup_gpio0(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + struct cs_spec *spec = codec->spec; + spec->gpio_eapd_hp = 0; + spec->gpio_eapd_speaker = 1; + spec->gpio_mask = spec->gpio_dir = + spec->gpio_eapd_hp | spec->gpio_eapd_speaker; + } +} + +static const struct hda_fixup cs4208_fixups[] = { + [CS4208_GPIO0] = { + .type = HDA_FIXUP_FUNC, + .v.func = cs4208_fixup_gpio0, + }, +}; + +static int patch_cs4208(struct hda_codec *codec) +{ + struct cs_spec *spec; + int err; + + spec = cs_alloc_spec(codec, 0); /* no specific w/a */ + if (!spec) + return -ENOMEM; + + spec->gen.automute_hook = cs_automute; + + snd_hda_pick_fixup(codec, cs4208_models, cs4208_fixup_tbl, + cs4208_fixups); + snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_PRE_PROBE); + + err = cs_parse_auto_config(codec); + if (err < 0) + goto error; + + codec->patch_ops = cs_patch_ops; + + snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_PROBE); + + return 0; + + error: + cs_free(codec); + return err; +} + +/* * Cirrus Logic CS4210 * * 1 DAC => HP(sense) / Speakers, @@ -991,6 +1064,7 @@ static int patch_cs4213(struct hda_codec *codec) static const struct hda_codec_preset snd_hda_preset_cirrus[] = { { .id = 0x10134206, .name = "CS4206", .patch = patch_cs420x }, { .id = 0x10134207, .name = "CS4207", .patch = patch_cs420x }, + { .id = 0x10134208, .name = "CS4208", .patch = patch_cs4208 }, { .id = 0x10134210, .name = "CS4210", .patch = patch_cs4210 }, { .id = 0x10134213, .name = "CS4213", .patch = patch_cs4213 }, {} /* terminator */ @@ -998,6 +1072,7 @@ static const struct hda_codec_preset snd_hda_preset_cirrus[] = { MODULE_ALIAS("snd-hda-codec-id:10134206"); MODULE_ALIAS("snd-hda-codec-id:10134207"); +MODULE_ALIAS("snd-hda-codec-id:10134208"); MODULE_ALIAS("snd-hda-codec-id:10134210"); MODULE_ALIAS("snd-hda-codec-id:10134213");
Hi Takashi,
OK, then try the patch below.
Great - that patch seems to do the trick, the speakers now are working perfectly :) One question - what is supposed to be responsible for muting the speakers with the headphones plugged in? I can switch between headphones and speakers with pavucontrol which works fine (alsamixer shows it simply mutes the speaker control when headphones are selected), but the speaker is not being automatically muted when headphones are plugged in - is that something that the driver is supposed to handle, or is that a userspace problem? Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
At Mon, 9 Sep 2013 23:26:11 +1000, Ian Munsie wrote:
Hi Takashi,
OK, then try the patch below.
Great - that patch seems to do the trick, the speakers now are working perfectly :)
One question - what is supposed to be responsible for muting the speakers with the headphones plugged in? I can switch between headphones and speakers with pavucontrol which works fine (alsamixer shows it simply mutes the speaker control when headphones are selected), but the speaker is not being automatically muted when headphones are plugged in - is that something that the driver is supposed to handle, or is that a userspace problem?
The speaker should be muted. But better to check without PulseAudio, as the recent PA itself may do the automute by checking the jack state controls. In anyway, give alsa-info.sh outputs before and after plugging the headphone. Takashi
Hi Takashi, On 10 September 2013 00:08, Takashi Iwai <tiwai@suse.de> wrote:
The speaker should be muted. But better to check without PulseAudio, as the recent PA itself may do the automute by checking the jack state controls.
In anyway, give alsa-info.sh outputs before and after plugging the headphone.
I've attached both runs of alsa-info.sh, though it looks like there was no change in the output after plugging in the headphones. Let me know what else I can do. Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
At Tue, 10 Sep 2013 00:48:53 +1000, Ian Munsie wrote:
Hi Takashi,
On 10 September 2013 00:08, Takashi Iwai <tiwai@suse.de> wrote:
The speaker should be muted. But better to check without PulseAudio, as the recent PA itself may do the automute by checking the jack state controls.
In anyway, give alsa-info.sh outputs before and after plugging the headphone.
I've attached both runs of alsa-info.sh, though it looks like there was no change in the output after plugging in the headphones.
Let me know what else I can do.
Check the value output by hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0 before and after plugging the headphone. Normally, the second line should show 0x80000000 after plugging the jack. If it shows only zero for both plug/unplug, either the headphone pin assignment is wrong or the jack detection is broken. In the former case, you can check by adjusting the headphone volume or mute mixer control and see whether it really happens on the machine. Takashi
Cheers, -Ian
-- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html [2 alsa-info.txt.VcBI1bV5oy <application/octet-stream (base64)>]
[3 alsa-info-headphones.txt.KeF9YbarKG <application/octet-stream (base64)>]
Hi Takashi,
Check the value output by
hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0
before and after plugging the headphone. Normally, the second line should show 0x80000000 after plugging the jack.
Doesn't look like it: ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 nid = 0x10, verb = 0x709, param = 0x0 value = 0x0 ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0 nid = 0x10, verb = 0xf09, param = 0x0 value = 0x0 <plug in headphones> ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 nid = 0x10, verb = 0x709, param = 0x0 value = 0x0 ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0 nid = 0x10, verb = 0xf09, param = 0x0 value = 0x0
If it shows only zero for both plug/unplug, either the headphone pin assignment is wrong or the jack detection is broken. In the former case, you can check by adjusting the headphone volume or mute mixer control and see whether it really happens on the machine.
I can confirm that adjusting the headphone volume & mute with alsamixer does correctly adjust the headphone volume, so I guess the jack detection isn't working. It seems that pulseaudio was doing some funny things with the mute controls (muting any one of headphones, speakers & master would mute all three & all would have to be individually unmuted before getting sound again - I guess pulseaudio doesn't expect anyone to adjust the sound card mixer directly while it is running), so I temporarily uninstalled it again for this test. One other weird thing I noticed while testing this is that setting the volume to 0% and/or muting does the controls does not seem to completely mute the sound - it is just really quiet (quiet enough not to be an issue for me). Some observations: __Speakers__ Master: Mute AND/OR Speakers: Mute --> Speakers are muted. Master: 0% AND Speakers: 0% --> Sound still comes from speakers, but is very quiet. Master: 0% --> speaker control affects volume. __Headphones__ Master: 0% AND/OR Headphones: 0% --> Sound still comes from headphones at low volume (if either control is 0%, the volume of the other control has no effect - both have to be non-zero to raise the volume). Master: Mute AND/OR Headphones: Mute --> Sound still comes from headphones, though is fairly quiet (much lower than 0%). Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
At Tue, 10 Sep 2013 01:48:05 +1000, Ian Munsie wrote:
Hi Takashi,
Check the value output by
hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0
before and after plugging the headphone. Normally, the second line should show 0x80000000 after plugging the jack.
Doesn't look like it:
ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 nid = 0x10, verb = 0x709, param = 0x0 value = 0x0 ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0 nid = 0x10, verb = 0xf09, param = 0x0 value = 0x0
<plug in headphones>
ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_SENSE 0 nid = 0x10, verb = 0x709, param = 0x0 value = 0x0 ian@button~ [i]> sudo hda-verb /dev/snd/hwC0D0 0x10 GET_PIN_SENSE 0 nid = 0x10, verb = 0xf09, param = 0x0 value = 0x0
OK, then the normal jack detection doesn't work with this machine, as it seems. You can try the above to all pins for checking if any of other pins reacts to the headphone jack.
If it shows only zero for both plug/unplug, either the headphone pin assignment is wrong or the jack detection is broken. In the former case, you can check by adjusting the headphone volume or mute mixer control and see whether it really happens on the machine.
I can confirm that adjusting the headphone volume & mute with alsamixer does correctly adjust the headphone volume, so I guess the jack detection isn't working.
It seems that pulseaudio was doing some funny things with the mute controls (muting any one of headphones, speakers & master would mute all three & all would have to be individually unmuted before getting sound again - I guess pulseaudio doesn't expect anyone to adjust the sound card mixer directly while it is running), so I temporarily uninstalled it again for this test.
One other weird thing I noticed while testing this is that setting the volume to 0% and/or muting does the controls does not seem to completely mute the sound - it is just really quiet (quiet enough not to be an issue for me). Some observations:
__Speakers__ Master: Mute AND/OR Speakers: Mute --> Speakers are muted.
Master: 0% AND Speakers: 0% --> Sound still comes from speakers, but is very quiet.
Master: 0% --> speaker control affects volume.
__Headphones__ Master: 0% AND/OR Headphones: 0% --> Sound still comes from headphones at low volume (if either control is 0%, the volume of the other control has no effect - both have to be non-zero to raise the volume).
Master: Mute AND/OR Headphones: Mute --> Sound still comes from headphones, though is fairly quiet (much lower than 0%).
The volume 0% doesn't mean that the volume is muted. But if the mute switch is set, it must mute the corresponding output. If not, it means that the codec lies, or the actual output doesn't come from the pin BIOS advertised. Takashi
One other weird thing I noticed while testing this is that setting the volume to 0% and/or muting does the controls does not seem to completely mute the sound - it is just really quiet (quiet enough not to be an issue for me). Some observations:
__Speakers__ Master: Mute AND/OR Speakers: Mute --> Speakers are muted.
Master: 0% AND Speakers: 0% --> Sound still comes from speakers, but is very quiet.
Master: 0% --> speaker control affects volume.
__Headphones__ Master: 0% AND/OR Headphones: 0% --> Sound still comes from headphones at low volume (if either control is 0%, the volume of the other control has no effect - both have to be non-zero to raise the volume).
Master: Mute AND/OR Headphones: Mute --> Sound still comes from headphones, though is fairly quiet (much lower than 0%).
Because the driver select the amp at the pin complex of the headphone instead of the amp at the audio output These amps have different dB min Node 0x02 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Device: name="ID 4208 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0x7f 0x7f] Converter: stream=8, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 13 samples Node 0x03 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0x7f 0x7f] Converter: stream=8, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 13 samples Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Jack", index=0, device=0 Amp-Out caps: ofs=0x42, nsteps=0x42, stepsize=0x03, mute=1 Amp-Out vals: [0x42 0x42] Pincap 0x0000001c: OUT HP Detect Pin Default 0x032b401f: [Jack] HP Out at Ext Left Conn = Comb, Color = Green DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x02
OK, then the normal jack detection doesn't work with this machine, as it seems. You can try the above to all pins for checking if any of other pins reacts to the headphone jack.
No luck I'm afraid - none of the other pins seem to react to the headphones. Is there anything else you can think of that I can try tomorrow? Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Hi Raymond,
Because the driver select the amp at the pin complex of the headphone instead of the amp at the audio output
These amps have different dB min
Ahh - this is starting to make sense to me now. I'll have to look at look_for_out_vol_nid like you suggested tomorrow. Cheers, -Ian -- http://sites.google.com/site/DarkStarJunkSpace -- http://darkstarshout.blogspot.com/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
At Tue, 10 Sep 2013 02:30:27 +1000, Ian Munsie wrote:
OK, then the normal jack detection doesn't work with this machine, as it seems. You can try the above to all pins for checking if any of other pins reacts to the headphone jack.
No luck I'm afraid - none of the other pins seem to react to the headphones. Is there anything else you can think of that I can try tomorrow?
Well, it might be notified via GPIO. Try to read GPIO pins except for GPIO0. That is, set the all unmasked, the direction to READ. hda-verb /dev/snd/hwC0D0 GPIO_SET_MASK 0x3f hda-verb /dev/snd/hwC0D0 GPIO_SET_DIR 0x01 Then read the values before and after the jack plug / unplug: hda-verb /dev/snd/hwC0D0 GPIO_GET_DATA 0 BTW, I'll be in a short leave in the next week, so the reply will be delayed. Takashi
participants (3)
-
Ian Munsie -
Raymond Yau -
Takashi Iwai