[PATCH 4/5] chtrt5645: Remove bogus JackHWMute settings

[Hans de Goede]

Hi,

On 4/6/20 5:17 PM, Pierre-Louis Bossart wrote:
> 
>>> So overall it seems rather unlikely that we can support dmic + headset mic in parallel?
>>
>> Right that is what the ConflictingDevices sections are for.
>>
>> Removing the JackHWMute does not allow using both add the same time,
>> it merely allows overriding which of the 2 to use (if the headset mic
>> is detected by the jack, the JackControl setting is kept).
>>
>> So lets say the internal mic is crappy, but the user prefers to
>> have their ears free, then they can use a headset around there neck,
>> using just the headset-mic and select speakers as output even though
>> a jack is inserted.
>>
>> Note pulseaudio will still automatically switch to the headphones /
>> headsetmic when plugged in, this merely allows overriding that
>> choice manually.
>>
>> Jacks which actually physically disable (or re-route) signals are
>> quite rare now a days so having a JackHWMute in the UCM conf is
>> often wrong. After this patch only a few cases are left:
>>
>> [hans at x1 alsa-ucm-conf]$ ack -l JackHWMute ucm2
>> ucm2/HDA-Intel/HiFi-dual.conf
>> ucm2/chtrt5650/HiFi.conf
>> ucm2/hda-dsp/HiFi.conf
>> ucm2/codecs/es8316/HeadPhones.conf
>> ucm2/sof-bdw-rt5677/HiFi.conf
>> ucm2/broxton-rt298/HiFi.conf
>> ucm2/skylake-rt286/HiFi.conf
>>
>> The es8316 case is actually correct, the es8316 has only 1
>> output (which is amplified for e.g. a speaker) and at
>> least the reference design suggests routing the speaker signal
>> through the jack and using a jack which will interrupt the
>> signal when headphones are plugged in.
>>
>> Note most actual designs implement this with an analog
>> switch and a GPIO to control that switch, since 3.5 mm
>> jacks which actually can disconnect a signal are rare
>> (if they exist at all, but I guess they do). For the
>> designs using the GPIO controlled analog switch, the
>> JackHWMute technically also is wrong, but I put it
>> there (IIRC it was me) because it matches the reference
>> design.
>>
>> I'm not familiar enough with any of the others to say anything
>> about them, but most of them are for HDA setups, where this
>> is somewhat more normal I guess.
> 
> If I follow the logic, I guess we should also remove the JackHWMute for sof-bdw-rt5677, hda-dsp and HDA-Intel. I can't think of a hardware limitation preventing the headset mic from being used while the speakers are used for playback. Likewise the rt5650 is a cheaper version of rt5645 so the same applies.

Right AFAIK:

JackHWMute "foo"

Means that the JackControl listed in the same section does
something at the hardware level which makes it impossible
for the "foo" input / output to function until the jack
is removed. Typically this would be something like actually
disconnecting the speakers at the electrical level.

So almost always using it is wrong.

Regards,

Hans