alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
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

      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).