Re: UCM modifier names

[Liam Girdwood <lrg@ti.com>]

Hi Stephen,

On 02/06/11 20:56, Stephen Warren wrote:
> Liam,
> 
> UCM syntax is e.g.:
> 
> SectionModifier."Capture Voice".0 {
> 
> This maps to a modifier->name of "Capture Voice.0".
> 
> However, when find_modifier searches for modifiers, it strips off the
> index (".0") from modifier->name, and just compares base name. As such,
> the index doesn't seem useful.
> 

Your right, the index is probably not very useful for modifiers atm. 

> I propose:
> 
> a) In parse_modifier, fail if index!=0.
> 
> b) In parse_modifier, store just the name in modifier->name.
> 
> c) In find_modifier, remove all the special handling of "." in the name,
>    and just strcmp(modifier->name, modifier_name).
> 
> Perhaps the index should be completely removed from the file syntax too?

Yeah, I would go with that for modifier.

> If an index was actually useful in any case, the author of the file could
> simply add it within the name string, i.e.:
> 
> typical: SectionModifier."Capture Voice" {
> 
> unusual: SectionModifier."Capture Voice 0" {
> 
> Of course, that wouldn't be backwards-compatible file syntax. Perhaps we
> could make the index optional, but always validate it was 0 if present,
> as I said above.
> 

we do have some users using the modifier.0 syntax so maybe best to deprecate it.

> I actually wonder if the index on the SectionDevice makes any sense
> either; functions like is_modifier_supported would be a lot simpler if
> devices simply never had an index, such that is_modifier_supported was
> a simple strcmp too. The worst fallout from that change might be a
> requirement to list more entries in SupportedDevice/ConflictingDevice.
> 

ok.

> 
> Second, when find_modifier is called from get_value, it'll fail with a
> valid modifier name that happens not to be supported on any currently
> active devices. Is that intended? I'd expect to be able to retrieve
> values from any/all devices and modifiers irrespective of whether those
> devices or modifiers could actually be activated given the currently
> active configuration.
> 
> I propose: Adding a parameter to find_modifier to indicate whether to
> call is_modifier_supported or not, this new parameter being false for
> get_value and true in other cases.
> 
> This issue will also be relevant to find_device when I modify that to
> call new function is_device_supported.
> 
> For find_device, we may also have to add a parameter for a device name
> that gets ignore when checking SupportedDevice/ConflictingDevice, which
> can be passed when switching devices.
> 
> Thanks for your thoughts.
> 

Sounds reasonable to me.

Liam