All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Some questions about userspace control elements
Date: Sun, 01 Feb 2015 18:50:18 +0100	[thread overview]
Message-ID: <54CE675A.80004@ladisch.de> (raw)
In-Reply-To: <54CE10D2.7090903@sakamocchi.jp>

Takashi Sakamoto wrote:
> 1.The 'numid' is unique number for each element or not?
> I want to use it to indicate each element, if possible. But there're
> more members in snd_ctl_elem_id structure.

The other members help with searching elements.  But numid itself must
be unique.

> 2.The 'numid' can be notified in SND_CTL_EVENT_MASK_ADD event?
> As long as I test, it's always zero when userspace applications add any
> elements. Is it an expected behaviour? Or a bug?

This looks like a bug in the kernel code.

All the other members of the id structure should be correct; as
a workaround, try calling snd_ctl_elem_info().

> 3.The way to change permissions of each control element.
> Is it possible after adding the elements? If possible, how to notify it
> in the other processes?

At the moment, this is not possible for userspace controls.

What bit(s) do you want to change?

> 4.Any elements added by a process are not removed at closing snd_ctl_t.
> They're remained after closing the process' snd_ctl_t. Is it an expected
> behaviour? Or a bug?

This is by design.  These controls are intended to be a property of the
device itself, and to be somewhat permanent.

> 5.Processes can delete elements which the other processes added.
> Is it an expected behaviour? Or a bug?

For permanent controls, it would not be possible to remember which
process created them originally.

> 6.The operation to replace elements generates separate events.
> ADD/REMOVE events occurs sequencially. Userspace application cannot
> distinguish replacement from adding/removing, therefore cannot process
> appropriate action. Is it an expected behaviour? Or a bug?

Replacement is just a shortcut for removing/adding.  So far, changing
the properties of userspace controls has not been necessary.


Regards,
Clemens

  reply	other threads:[~2015-02-01 17:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01 11:41 Some questions about userspace control elements Takashi Sakamoto
2015-02-01 17:50 ` Clemens Ladisch [this message]
2015-02-02 14:14   ` Takashi Sakamoto
2015-02-04 23:51   ` Takashi Sakamoto
2015-02-05  0:44     ` Takashi Sakamoto
2015-02-06  9:38       ` Clemens Ladisch
2015-02-07  1:58         ` Takashi Sakamoto
2015-02-07 15:45           ` Clemens Ladisch
2015-02-08 10:57             ` Takashi Sakamoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54CE675A.80004@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=o-takashi@sakamocchi.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.