On Mon, 2015-03-30 at 09:54 +0200, David Henningsson wrote: > > On 2015-02-12 14:11, Tanu Kaskinen wrote: > > "JackHWMute" is a UCM device value that, if set, indicates that the > > jack of the device mutes some other device at the hardware or driver > > level. A common example would be a headphone jack that mutes built-in > > speakers. PulseAudio should show such auto-muted devices as > > unavailable. > > > > Previously there was only a simple relationship: each UCM device was > > related to one jack and vice versa. Now each device is still related > > to exactly one jack, but each jack can be related to two devices: one > > that the jack enables, and one that the jack disables (mutes). > > Sorry for chiming in this late, but... > > Can we instead duplicate the jack, like we do for non-UCM, and set > jack->state_plugged -> PA_AVAILABLE_NO / jack->state_unplugged -> > PA_AVAILABLE_YES for the HWMute jack functionality? I suppose that's possible. I dislike that, because it means that the jack object doesn't actually represent a jack at all, not even a jack kcontrol. Instead, it represents the association between a device and a jack kcontrol. But if you prefer to do it that way, I'll do it that way. Some background on why I wrote the patch as I did: I would like to have only one jack object per physical jack, but that's unfortunately not possible, because there may be multiple jack kcontrols per physical jack, and AFAIK there's no API to find out about related jack kcontrols. The next best thing would be to have one jack object for each jack kcontrol, but I decided that since I'm anyway going to have to give up on the "one jack object per physical jack" ideal, maybe it's better to just use the model that UCM uses. In UCM, jacks are per-device things (meaning that each device has to repeat the jack configuration if there are multiple devices using the same jack), so I created one jack per UCM device. Now you want to further increase the duplication, with the benefit that the jack model in the UCM code would match the traditional mixer code, at the cost of introducing a mismatch with the underlying UCM model. I can live with that. Another thing: you said jack->state_unplugged would set the state to PA_AVAILABLE_YES, but in the traditional mixer config speakers are set to state PA_AVAILABLE_UNKNOWN when headphones are unplugged. Do you think it should be different with UCM? > It looks like this would enable us to share code between UCM and non-UCM > code paths instead of duplicating similar functionality. > > Also, we would then get automatic support for use cases like "Line Out" > which should only be available if both a) "Line Out Jack" is plugged in > and b) "Headphone Jack" is unplugged. In my patch I decided to not support a situation where one jack makes a device available and another jack makes it unavailable, because of the ambiguity. If we want to support the use case you mention, I guess the UCM spec should explicitly say that JackHWMute overrides JackControl, otherwise we'd be relying on undefined behaviour. > Btw, I also agree with Arun that ports should be of unknown availability > in case they have no jacks at all connected to them. I agree too. -- Tanu
