On Tue, 25 Jun 2019 13:41:58 +0200, Hui Wang wrote:
On 2019/6/25 下午7:05, Takashi Iwai wrote:
On Tue, 25 Jun 2019 08:02:45 +0200, Yang, Libin wrote:
Sorry for a long delay for the hdmi jacks. I was busy on another critical issue last 2 weeks. I have worked out the UCM configuration files. Please check the attachment. It is a long file, so I use the attachment instead of the patch mode. Based on my test, it works well. Could you please help review if the configuration file is OK or not. I will do more test on the meantime, including DPMST and NON-DPMST.
With some more tests on the new hdmi jack with UCM configuration, I found that the kernel patch can always notify the jack hotplug event to userspace correctly. However, the userspace can't set the amixer correctly based on the UCM configurations sometimes.
Here is the details: There are 3 PCMs on Intel platforms. Let's call them pcm1, pcm2, pcm3. And there are 3 pins (pin5, pin6, pin7). For DPMST, and each pin has 3 ports: port0, port1, port2.
For non-DPMST, we can set pin5 <=> pcm1, pin6 <=> pcm2, pin7 <=> pcm3. This can always work.
For DPMST, as there are 9 ports using 3 pcms. So we should assign 1 pcm to 3 ports. For example, pin5-port0, pin6-port1 and pin7-port2 are using pcm1; pin5-port1, pin6-port2 and pin7-port0 are using pcm2; pin5-port2; pin6-port3 and pin7-port1 are using pcm3. In this setting, we should setting the ConflictingDevice in UCM. For example, pin5-port0 is conflicting with pin6-port1 and pin7-port2. Hui and I found if we set one device conflicting with 2 devices, the amixer setting will be wrong and it will not following UCM configuration setting when we are hotplugging the monitors.
How wrong would it behave? Only one of them is done?
Yes, only the 1st conflicting device is handled.
for example:
pin5-port0 has two conflicting devices: pin6-port1 and pin7-port2,
When pin5-port0 is active in the pulseaudio, I can see the pin6-port1.DisableSequece and pin7-port2.DisableSequence are called according to pulseaudio's log, but it looks like the commands only in the 1st device (pin6-port1.DisableSequence) are executed.
To call conflicting devices' disablesequence, the pulseaudio will call snd_use_case_set(ucm->ucm_mgr, "_disdev", dev_name) twice, but only the 1st time calling takes effect.
If you reached at that point, you can continue tracking in alsa-lib :) If it's some weird behavior in set_device(), it must be either the list management failure in UCM or execute_sequence() misses something.
thanks,
Takashi