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

Hi Clemens,

Thanks for your answer. I want to discuss about the design of ALSA
userspace controls with you, while today I've read some related kernel
codes and realized they're more buggy than I expected...perhaps. I'd
like to start discussion after fixing them.


Thanks

Takashi Sakamoto

On Feb 2 2015 02:50, Clemens Ladisch wrote:
> 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-02 14:14 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
2015-02-02 14:14   ` Takashi Sakamoto [this message]
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=54CF864F.8060208@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    /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.