[alsa-devel] [PATCH v2 0/5] topology: Enhance support for private data
Takashi Sakamoto
o-takashi at sakamocchi.jp
Tue Jul 19 07:14:12 CEST 2016
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
More information about the Alsa-devel
mailing list