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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
