On 2015-03-31 19:32, Tanu Kaskinen wrote: > 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. I'd hate to tell a person to start from scratch again just based on my preference - Arun, what do you think? > 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. I'm trying to understand how this description fits with your actual patch, but I'm having troubles understanding how the objects fit together. First, you add both "port" and "pa_alsa_ucm_port" structs. What's the difference? Also, both contain pointers to variable called "core_port". Does this also mean there are non-core ports? What's the difference between a "core_port" and "non-core ports"? Second, a pa_alsa_ucm_device has an array of pa_alsa_ucm_ports, and a pa_alsa_ucm_port has an array of pa_alsa_ucm_devices. I have a hard time understanding this, could you give a realistic example where there is more than one port per device that in turn has more than one device per port? Third, JackHWMute per UCM documentation says something like "this jack mutes another device". If the availability of ucm devices are solely set by the jack (right?), then this is effectively a ucm_device to ucm_device connection, where you can set one ucm_device's availability based solely on the other ucm_device. I don't really see why you need to add these crossreference port structs at all. > 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? Sorry, I'll correct myself. It would be better to toggle between NO and UNKNOWN, for consistency. That said; I'd want the non-UCM stuff ideally to toggle between NO and YES too, but that's a different discussion. >> 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. Actually I'd say it's an "and" relation rather than one overrides the other; i e, the device is available only if (JackControl.plugged_in && !JackHWMute.plugged_in). -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
