Hi Takashi,
On Mon, Sep 02, 2019 at 08:41:48AM +0200, Takashi Iwai wrote:
Simpler...yes and no :) From what I have seen, all "default" Pulse profiles are replaced by the UCM, meaning that if I wanted them, I'd have to replicate all of them in my conf. It would work though.
You just need to override codec->card->longname to some unique string and use it as UCM profile name. Check alc1220_fixup_gb_dual_codecs() as an example.
no, no, that's not what I meant. I did understand how to tell PulseAudio which UCM to load, i.e. via the longname just as you wrote above.
However, what I then observed was: PulseAudio loads my UCM configuration and pavucontrol lists only the profiles which I have specified in the UCM.
So what I was trying to say is that I lose all the stock profiles that PulseAudio creates automatically and that list is quite long (i.e. Analog Surround 5.1 Output + Analog Stereo Input, same for 5.0, 4.1, 4.0 and so on), basically the stock profiles get dropped in favor of the ones that I provide in the UCM.
Meanwhile I also figured out that /proc/asound/card0/codec#0 is providing this info as well:
IO[1]: enable=0, dir=1, wake=0, sticky=0, data=0, unsol=0
So the value seems to be 0 and I can add an explicit SET_GPIO_DATA verb quirk to set it in addition to SET_GPIO_DIRECTION, right?
Yes. You need to set SET_GPIO_MASK=0x02, SET_GPIO_DIRECTION=0x02 and SET_GPIO_DATA=0x00 for that bit.
Thanks a lot, I read the hda-intel spec on GPIOs a couple of times, but I was somehow not getting the idea about the GPIO MASK, now it's clear what I was missing. I'll add those three verbs to my quirk.
[...]
The above seems to work quite well for me and does exactly what I want, PulseAudio presents all the autogenerated profiles and handles mic and line jacks itself, at the same time all unwanted speakers get muted as soon as I plug in my headphones into the jack pin that is shared with my surround speakers. Of course Pulse does not "know" anything about the headphones and does not switch profiles, but I don't mind since the user experience is as expected.
Hm, OK, this amount of changes are acceptable. The hardware behavior itself is weird, and we have already tricky code, so it's no problem to keep some yet another tricky code as long as it's described enough in the comments and the changelog.
Great, thank you! I will prepare a patch then, I like this approach a lot more than the UCM variant.
My earlier attempt was to send the pin widget control verbs directly, however then the pin got reconnected as soon as playback started. This does not happen when I use snd_hda_set_pin_ctl_cache(), but I am not quite sure about the cache, should I use the _cache function or the uncached one?
This should work, AFAIK. The *_set_pin_ctl_cache() remembers the last written value, as its name stands. That's restored again at the PM resume, for example.
The PM resume does re-trigger the jack detection callback, so it'll be written up again in anyway, though.
Thanks for the explanation, seems I picked the right function.
Another thing I am not sure about is, if I somehow disrupt power management by doing what I do? I saw that for instance restore_shutup_pins() does modify those connections as well and I would basically overwrite whatever it did in the case that the user plugs/unplugs the headphones.
This should be fine as-is. The shutup_pins() clears pins temporarily and the pins are resumed to the cached values in return.
I was more thinking of the scenario that shutup_pins() cleared them, some time afterwards the user unplugs headphones which triggers my jack-detect callback where I reconnect the pins, although the "shutup" condition is still valid. Maybe I'm overthinking it. If this is not a problem, then I'm indeed almost done - easier than I thought :)
One thing to be improved would be to drop the surround jack control. Adjust the pin config to different value with the fixed pin connection, so that the auto-parser won't create the "Surround Jack" control. This isn't needed by PA or else, otherwise it may be confusing.
Hmm, if I understand you correctly, then you are referring to bits 31:30 Port Connectivity?
It does not seem to work that way... I tried all combinations and I either lose jack detect support or I lose the 5.1 profile in Pulse.
With these settings snd_hda_jack_detect_state() never returns HDA_JACK_PRESENT: 0x91130012 [Fixed] Speaker at Int Rear 0xd1130012 [Both] Speaker at Int Rear
I can plug or unplug, I get called, but I always receive HDA_JACK_PHANTOM
snd_hda_jack_detect_state() works fine with "no physical connection to port": 0x51130012 [N/A] Speaker at Int Rear
But with the above pin setting I "lose" the 5.1 profile in Pulse...
Which leaves me with with what I had before: 0x11130012 [Jack] Speaker at Int Rear
Am I missing something or did you mean some other setting? Should I be using a different function instead of snd_hda_jack_detect_state() to check my jack state in the callback?
I will study the kernelnewbies howto a bit more (it's my first kernel patch submissoin) and will follow up with a patch soon.
Thank you very much for your help! I would not have come so far without your support, really happy that my audio finally works :)
Kind regards, Jin