[alsa-devel] [PATCH v2 0/5] topology: Enhance support for private data

[Takashi Sakamoto]

On Jul 19 2016 12:59, Vinod Koul wrote:
>> Yes, you're right. snd_ctl_new1() dropped SNDRV_CTL_ELEM_ACCESS_USER flag.
>> I'll remove this from the topology user space tool to avoid confusion.
>
> Oh no, that won't be a good idea.
>
> We would like to specify the access for controls from topology. Some
> controls can be read only and some write only :)
>
> For example, any VU-meter controls should be read-only. Similarly if we have
> some user data being sent to some modules which can do do all fancy audio
> detection then these controls should be write-only.

?

I just suggested to remove 'user' from topology implementation in 
userspace library. You can still control access rights of control 
elements by adding enough flags; 'read' or 'write' 
(SNDRV_CTL_ELEM_ACCESS_READ or SNDRV_CTL_ELEM_ACCESS_WRITE). 
SNDRV_CTL_ELEM_ACCESS_USER has no relationship to your purposes.

When a control element has SNDRV_CTL_ELEM_ACCESS_USER flag, a control 
element set including the element has below operations;
  - struct snd_kcontrol.info = snd_ctl_elem_user_enum_info or
                               snd_ctl_elem_user_info
  - struct snd_kcontrol.get = snd_ctl_elem_user_get
  - struct snd_kcontrol.put = snd_ctl_elem_user_put
  - struct snd_kcontrol.tlv.c = snd_ctl_elem_user_tlv

When userland applications call ioctl(2) with SNDRV_CTL_IOCTL_ELEM_ADD, 
then ALSA ctl core adds new control element set. The 'USER' flag is used 
only for this case.

I think it better for you to read 'sound/core/control.c' or my test 
program in alsa-lib source.
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=test/user-ctl-element-set.c


Regards

Takashi Sakamoto