Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Oder Chiou <oder_chiou@realtek.com>,
	alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Brown <broonie@kernel.org>, Bard Liao <bard.liao@intel.com>
Subject: Re: [RFC 2/2] ASoC: rt5670: Add LED trigger support
Date: Wed, 24 Feb 2021 11:33:32 +0100	[thread overview]
Message-ID: <s5hv9ahsqkj.wl-tiwai@suse.de> (raw)
In-Reply-To: <03068e15-2157-3ae6-ffd6-7ec315bb49a3@perex.cz>

On Wed, 24 Feb 2021 10:49:41 +0100,
Jaroslav Kysela wrote:
> 
> Dne 24. 02. 21 v 10:38 Takashi Iwai napsal(a):
> 
> >> It seems that you misunderstood the number of issues which my code is trying
> >> to resolve:
> >>
> >> 1) set LED based on state from multiple cards (so you cannot trigger LED
> >> inside single driver / single control element); we need one arbiter; this is
> >> the main argument
> >> 2) unifies the audio LED interface
> >> 3) reduce the hardware driver code
> > 
> > Those purposes are all fine.  But they don't need to be exposed for
> > user controls that can be abused.  That's the very concern.
> 
> So, how to handle this feature for AMD ACP without PA / PipeWire modifications?
> 
> And if we add an user space channel to the audio LED arbiter code, how it
> differs from my proposed control API extension?

As the early patch does, creating a kernel control (but not a generic
"Capture" switch but specific to LED) and control it in UCM profile.
What's the practical problem there?  That's what I might have missed
as the starting point of the discussion.

> We have already locking
> mechanism for the user control element to one task, so it's possible to create
> safe user space implementation (depending on the standard task priviledges) on
> demand even with my proposal.
> 
> Could you elaborate the abuse you mean? Three bits?

You can create up to 1028 user controls per card and each of them can
fire the led trigger...  That's an interesting experiment :)

So far, a user control is merely storing the value, let read/write via
the control API.  That's all, and nothing wrong can happen just by
that.  Now if it interacts with other subsystem...

A more serious concern is rather the fragility of the setup; for
enabling the mute LED control, you'd have to create a new user-space
control, the function of the control has to be ignored by some
application and some not, etc.  This has to be done on each machine
when the system got updated.  And, not everyone is using alsa-lib.
Does tiny ALSA and other existing backend support the user control
element management?  Some uncertainty here.


thanks,

Takashi

  reply	other threads:[~2021-02-24 10:34 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 14:24 [RFC 0/2] ASoC: rt5670: Add LED trigger support Hans de Goede
2021-02-15 14:24 ` [RFC 1/2] ASoC: Add new SOC_DOUBLE*_ACCESS() macros Hans de Goede
2021-02-15 14:24 ` [RFC 2/2] ASoC: rt5670: Add LED trigger support Hans de Goede
2021-02-23 13:45   ` Mark Brown
2021-02-23 13:59     ` Hans de Goede
2021-02-23 14:09       ` Mark Brown
2021-02-23 14:21         ` Takashi Iwai
2021-02-23 16:14           ` Jaroslav Kysela
2021-02-23 16:20             ` Takashi Iwai
2021-02-23 20:56               ` Jaroslav Kysela
2021-02-24  7:12                 ` Takashi Iwai
2021-02-24  8:14                   ` Jaroslav Kysela
2021-02-24  8:52                     ` Takashi Iwai
2021-02-24  9:27                       ` Jaroslav Kysela
2021-02-24  9:38                         ` Takashi Iwai
2021-02-24  9:49                           ` Jaroslav Kysela
2021-02-24 10:33                             ` Takashi Iwai [this message]
2021-02-24 10:56                               ` Jaroslav Kysela
2021-02-24 11:43                                 ` Takashi Iwai
2021-02-24 12:08                                   ` Jaroslav Kysela
2021-02-24 12:42                                     ` Takashi Iwai
2021-02-24 17:57                                       ` Jaroslav Kysela
2021-02-25 11:00                                         ` Takashi Iwai
2021-02-25 18:09                                           ` Jaroslav Kysela
2021-02-26  8:41                                             ` Takashi Iwai
2021-02-26  9:22                                               ` Jaroslav Kysela
2021-02-23 17:07             ` Hans de Goede
2021-02-23 17:20             ` Mark Brown
2021-02-23 19:03               ` Hans de Goede
2021-02-24 12:59                 ` Mark Brown
2021-02-24 19:14                   ` Hans de Goede
2021-02-24 19:36                     ` Mark Brown
2021-02-24 20:09                       ` Hans de Goede
2021-02-25 14:59                         ` Mark Brown
2021-02-25 18:45                           ` Hans de Goede
2021-03-01 13:23                             ` Mark Brown
2021-03-01 13:39                               ` Hans de Goede
2021-03-01 19:15                                 ` Mark Brown
2021-03-01 19:49                                   ` Hans de Goede
2021-03-01 20:43                                     ` Mark Brown
2021-03-01 21:26                                       ` Hans de Goede
2021-03-02 12:41                                         ` Mark Brown
2021-03-02 21:14                                         ` Jaroslav Kysela
2021-03-04 19:39                                           ` Hans de Goede
2021-03-05 13:02                                             ` Jaroslav Kysela
2021-03-07 13:51                                               ` Hans de Goede

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=s5hv9ahsqkj.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=broonie@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=lgirdwood@gmail.com \
    --cc=oder_chiou@realtek.com \
    --cc=perex@perex.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox