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