Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: "Juho Hämäläinen" <juho.hamalainen@tieto.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: UCM {Supported,Conflicting}Device confusion
Date: Wed, 29 May 2013 09:12:42 -0600	[thread overview]
Message-ID: <51A61AEA.4050602@wwwdotorg.org> (raw)
In-Reply-To: <51A5DEAA.4020007@tieto.com>

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.

      reply	other threads:[~2013-05-29 15:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29 10:55 UCM {Supported,Conflicting}Device confusion Juho Hämäläinen
2013-05-29 15:12 ` Stephen Warren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A61AEA.4050602@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=juho.hamalainen@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox