On 05/29/2013 04:55 AM, Juho Hämäläinen wrote:

Hello,

Firstly as a sidenote, Supported/Conflicting is checked only one-way, if say devices A and B are enabled and say B has ConflictingDevice "C", and device C doesn't list anything, enabling of C is possible (and after that disabling C is not possible before B is disabled first).

It's been a long time since I touched the ConflictingDevice stuff, but IIRC the idea was that every device would include a complete list of Supported/Conflicting Devices, so there was only a need to check "one way".

Now, looking at the way SupportedDevice and ConflictingDevice are implemented in ucm and I came to following conclusion:

If no SupportedDevice or ConflictingDevice: All devices and combinations are compatible, so implicit "SupportedDevice ALL".

If SupportedDevice is listed: Device can be enabled as long as at least one enabled device is in SupportedDevice list.

If ConflictingDevice is listed: Device can be enabled if none of active devices are in ConflictingDevice list (noting aforementioned limit in checking this)

This is at least how I figured all combinations of multiple devices can be defined with only zero or one either SupportedDevice or ConflictingDevice entry per device.

Did I understand this right?

That sounds about right, from my rusty memory.

Oh, the commit log specifies the behaviour:

UCM: Implement ConflictingDevices, add device list to devices

Wherever SupportedDevice can appear, also allow ConflictingDevice. Only
one or the other (or neither) may be specified. When neither is
specified, allow anything. Sometimes, listing ConflictingDevices may
result in a shorter list than explicitly listing all SupportedDevices.

Add support for SupportedDevice and ConflictingDevice to SectionDevice.
This allows representing devices which are mutually exclusive, e.g. due
to a mux that switches between capturing from two different microphones,
without the possibility of mixing.

Enhance is_modifier_supported to allow ignoring SupportedDevice and
ConflictingDevice. This is useful when querying values from a
SectionModifier; there's no reason we shouldn't be able to query values
just because the current configuration would prevent enabling that
device. The new is_device_supported is implemented similarly.

Enhance switch_device to remove the old device from the current device
list before querying for the new device, and add it back immediately
afterwards. This allows the query for the new device to ignore any
conflicts caused solely by the old device.