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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
