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-s...
Regards
Takashi Sakamoto