1) ---
The Speaker in general doesn't have corresponding jack, so its availability is "unknown".
When it's legacy HDA, once a Headphone is plugged, PulseAudio will disable all "unknown" profiles, so the speaker is gone in this case.
When it's DMIC, the disablement of "unknown" profile is skipped because it's using UCM.
2) ---
The headset jack plug may or may not have ability to determine jack type (i.e. what gets plugged in), and that creates two different behaviors:
- When the hardware can determine jack types like most HP and Lenovo hardwares, libgnome-volume-control checks PA status and switches to corresponding device
- When the hardware _cannot_ determine jack types like most Dell hardwares, libgnome-volume-control leaves all possible option available. For instance, when something gets plugged in, the system doesn't know it's headphone, mic, or a headset, so it has to leave all options to the user and user is responsible to choose the right device.
Update from https:/ /bugs.launchpad .net/stella/ +bug/1948777:
1) ---
The Speaker in general doesn't have corresponding jack, so its availability is "unknown".
When it's legacy HDA, once a Headphone is plugged, PulseAudio will disable all "unknown" profiles, so the speaker is gone in this case.
When it's DMIC, the disablement of "unknown" profile is skipped because it's using UCM.
2) ---
The headset jack plug may or may not have ability to determine jack type (i.e. what gets plugged in), and that creates two different behaviors:
- When the hardware can determine jack types like most HP and Lenovo hardwares, libgnome- volume- control checks PA status and switches to corresponding device
- When the hardware _cannot_ determine jack types like most Dell hardwares, libgnome- volume- control leaves all possible option available. For instance, when something gets plugged in, the system doesn't know it's headphone, mic, or a headset, so it has to leave all options to the user and user is responsible to choose the right device.