On Thu, Jun 09, 2022 at 06:19:37PM +0200, Martin Povišer wrote: > > On 9. 6. 2022, at 17:50, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Can you say anything more about the use case? > I can restate: The alleged use case is running userspace without sound > server, but having playback switch transparently between speakers and > headphones even mid-stream based on jack detection. Sure, but why? > > No, that works perfectly fine - you can enable or disable pins depending > > on the jack state. > Ah, I peeked into soc-jack.c. What about this then: If I understand what > pins represent, they would be at the remote end of the DAPM paths. So if > for the speakers I add something like > Headphones Codec Out —> Jack pin > > +--> Always-on pin > | > Speaker Amp Out -> Mux > | > +--> Jack inverted pin > and let userspace control the mux, it would in effect support the same > use cases as what I attempted in the code so far. Sounds somewhat right? Yes, that should DTRT. If the mux is working properly with DAPM (not sure it does with DPCM but ICBW) then you shouldn't even need the jack integration since the mux would disconnect the unused output when it gets switched.
Attachment:
signature.asc
Description: PGP signature
