From: Raymond Yau <superquad.vortex2@gmail.com>
To: Takashi Iwai <tiwai@suse.de>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>
Subject: Re: snd jack report and unsolicited event ad1988
Date: Wed, 18 May 2011 10:10:32 +0800 [thread overview]
Message-ID: <BANLkTinLyZW7HO1nV+tXso2LGtipD25rLw@mail.gmail.com> (raw)
In-Reply-To: <s5haaewjcrz.wl%tiwai@suse.de>
2011/5/9 Takashi Iwai <tiwai@suse.de>:
> At Mon, 9 May 2011 11:56:11 +0800,
> Raymond Yau wrote:
>>
>> 2011/5/5 Takashi Iwai <tiwai@suse.de>
>>
>> >> This mean that the driver need to define FRONT_MIC_EVENT, REAR_MIC_EVENT,
>> >> LINE_IN_EVENT in addition to HP_EVENT
>>
>> >Does it mean that the codec can't accept the same id tag for multiple
>> >pins?
>>
>> No, the event can be received by the event handler but there is no way to
>> know the event is related to which jack
>
> Yeah, sure, if you want to distinguish each pin, you have to assign
> different ids. But it's independent from my question.
>
> Your statement sounded as if the multiple pins aren't allowed to have
> the same tag on AD codec. But, it seems that it's OK, judging from
> your follow up.
>
If you assign the same tag, you have to perform snd_jack_detect() on
multiple pin complex and the driver won't know exactly which jack is
plugged in/out unless it store the previous state of 8 jacks
>
>> >> Can snd_jack_report used to report the mic event of two pink jacks
>> (front
>> >> panel and rear panel) of the desktop to the user space program?
>>
>> > I assumed so, but someone needs to confirm.
>> > Assigning different tags is easy and safe, so even if it worked, we
>> > can go forward for individual tags.
>>
>> So the point is whether the user space program need to know
>>
>> 1) the event is related to the plug in or out of the front mic jack / rear
>> mic jack
>> 2) whether earphone or speaker is plugged into correct/wrong jacks by
>> measured impedance .
>
> In some time future, yes, a program like PulseAudio would like to know
> and behave reactively to the plug state. But, in that case, the whole
> driver design should be changed -- the kernel driver should do as
> little as possible regarding the jack task switching.
>
Do snd_jack_report allow the driver to add two jacks input for front
mic and rear mic ?
>>
>> So, adding some delay like below makes it working?
>> >
>>
>> if (!codec->no_trigger_sense) {
>> > pincap = snd_hda_query_pin_caps(codec, nid);
>> > - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
>> > + if (pincap & AC_PINCAP_TRIG_REQ) { /* need trigger? */
>> > snd_hda_codec_read(codec, nid, 0,
>> > AC_VERB_SET_PIN_SENSE, 0);
>> > + if (codec->trigger_delay > 0)
>> > + mdelay(codec->trigger_delay);
>> > + }
>> > }
>> > return snd_hda_codec_read(codec, nid, 0,
>> > AC_VERB_GET_PIN_SENSE, 0);
>> >
>>
>> Noise appear when delay is add at here
>
> In which situation? From unplugged to plugged?
>
>> Have to wait until someone find a safe way to get the impedance without any
>> side effect
>
> Looks so.
The noise appear until system shutdown
>
>> spec->vmaster_nid = 0x04;
>> >
>> > - codec->no_trigger_sense = 1;
>> > + /* codec->no_trigger_sense = 1; */
>> > + codec->trigger_delay = 5;
>> > codec->no_sticky_stream = 1;
>> >
>> > return 0;
>> >
>>
>>
>> So no need to change if the objective of snd_hda_jack_detect() is to get
>> presence detect bit
>>
>> As mentioned in 729d55ba972348234759f8e40abf8d
>> e020f0d505
>>
>> use tigger at pin-sensing seem generate a lot of responses
>
> When the unsol events are triggered, more exactly?
> If these are issued at once, the events can be filtered out by
> checking some flag or checking some timeout, etc. If an event is
> still triggered at 100ms after the actual plugging, it's a bit
> problem...
>
my unsol event handler just perform jack detect according to the tag
and print the result to system log only and still don't have any
mute/unmute statement
It seem that the following command also trigger a repsonse to
unsol_event handler
./hda-verb /dev/snd/hwC1D0 0x12 SET_PIN_SENSE 0
nid = 0x12, verb = 0x709, param = 0x0
value = 0x0
dmesg
unsol event res 48000000 tag 12
pincap 1014010 : 12 no jack detected Color = Green Line Out at Ext Rear
./hda-verb /dev/snd/hwC1D0 0x16 SET_PIN_SENSE 0
nid = 0x16, verb = 0x709, param = 0x0
value = 0x0
dmesg
unsol event res 58000000 tag 16
pincap 1011012 : 16 sense 1e Color = Black Line Out at Ext Rear
prev parent reply other threads:[~2011-05-18 2:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 7:05 snd jack report and unsolicited event ad1988 Raymond Yau
2011-05-05 9:50 ` Takashi Iwai
2011-05-09 3:56 ` Raymond Yau
2011-05-09 12:09 ` Takashi Iwai
2011-05-18 2:10 ` Raymond Yau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTinLyZW7HO1nV+tXso2LGtipD25rLw@mail.gmail.com \
--to=superquad.vortex2@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).