All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.de>
Cc: ALSA development <alsa-devel@alsa-project.org>,
	Curtis Malainey <cujomalainey@google.com>,
	Perry Yuan <Perry.Yuan@dell.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Brown <broonie@kernel.org>, Dylan Reid <dgreid@google.com>
Subject: Re: [PATCH v4 6/6] ALSA: led control - add sysfs kcontrol LED marking layer
Date: Tue, 23 Mar 2021 13:22:51 +0100	[thread overview]
Message-ID: <e9ff74df-4ca1-390b-b906-81019c0cf66d@perex.cz> (raw)
In-Reply-To: <s5hy2eeaysg.wl-tiwai@suse.de>

Dne 23. 03. 21 v 12:34 Takashi Iwai napsal(a):

>>> The simpler implementation in the kernel side is always nicer, but of
>>> course only if it works sufficiently.  So it depends on how much we
>>> want to support this feature.  The parse of control name can be done
>>> by scripting, but it's cumbersome for now, indeed, so if the shell
>>> scripting is seen as the major usage, it'd be more convenient if the
>>> kernel parses the string, yeah.
>>>
>>>>> - Do we have to deal with binding with multiple controls to a single
>>>>>   mute LED?  Might a single exclusive binding make things easier?
>>>>>   Then we don't have to create sysfs entries per card, and it'll be
>>>>>   something like
>>>>>      echo 1:10 > /sys/devices/virtual/sound/ctl-led/mic/bind
>>>>>   which is equivalent with the API call above.
>>>>>   If multiple bindings are attempted, it can simply give an error.
>>>>>   In the driver side, it catches the unexpected binding, too.
>>>>
>>>> AMD ACP digital + HDA analog headset microphone. If we follow the standard HDA
>>>> behaviour, both inputs should trigger the mic LED. Two cards are in the game.
>>>
>>> And that brings yet another question.  If the Dell privacy thing comes
>>> to play here, for example, the mute LED is tied with the hardware
>>> control of the built-in mic.  Then do we influence on this depending
>>> on the headset mic mute state, too?
>>
>> What users expect? I think that both scenarios are valid, thus we should allow
>> them.
> 
> IMO, this is a hard part.  It's possible that user (or the system)
> wants two different scenarios:
> - LED indicates the built-in mic mute
> - LED indicates the mute state of the currently used input
> 
> The current code assumes the latter case, and that might conflict with
> the concept of Dell privacy stuff (as the built-in mic is still
> allowed while using the headset).
> 
> How would be a good way to switch to a different scenario?

[Adding Perry /Dell/ to the discussion]

It's an user space setup. We can manage some conditional settings in UCM and
the shell scripts can be written with conditional parts. Perhaps, a global
configuration file(s) in /etc/alsa may specify the requested scenario.

I would just start with a default behavior (which may be hw specific) and
refine this later.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

  reply	other threads:[~2021-03-23 12:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 17:29 [PATCH v4 0/6] ALSA: control - add generic LED API Jaroslav Kysela
2021-03-17 17:29 ` [PATCH v4 1/6] ALSA: control - introduce snd_ctl_notify_one() helper Jaroslav Kysela
2021-03-17 17:29 ` [PATCH v4 2/6] ALSA: control - add layer registration routines Jaroslav Kysela
2021-03-17 17:29 ` [PATCH v4 3/6] ALSA: control - add generic LED trigger module as the new control layer Jaroslav Kysela
2021-03-17 17:29 ` [PATCH v4 4/6] ALSA: HDA - remove the custom implementation for the audio LED trigger Jaroslav Kysela
2021-03-17 17:29 ` [PATCH v4 5/6] ALSA: control - add sysfs support to the LED trigger module Jaroslav Kysela
2021-03-17 17:29 ` [PATCH v4 6/6] ALSA: led control - add sysfs kcontrol LED marking layer Jaroslav Kysela
2021-03-19 16:34   ` Hans de Goede
2021-03-19 17:22     ` Takashi Iwai
2021-03-19 17:58       ` Jaroslav Kysela
2021-03-19 22:08       ` Hans de Goede
2021-03-20  7:41         ` Takashi Iwai
2021-03-20  9:17           ` Hans de Goede
2021-03-20  9:48             ` Takashi Iwai
2021-03-22 14:16               ` Jaroslav Kysela
2021-03-23  9:38                 ` Takashi Iwai
2021-03-23  9:49                   ` Takashi Iwai
2021-03-23 10:31                     ` Jaroslav Kysela
2021-03-23 10:42                       ` Hans de Goede
2021-03-23 11:03                         ` Takashi Iwai
2021-03-23 10:50                       ` Takashi Iwai
2021-03-23 11:13                         ` Jaroslav Kysela
2021-03-23 11:34                           ` Takashi Iwai
2021-03-23 12:22                             ` Jaroslav Kysela [this message]
2021-03-23 21:39                 ` Curtis Malainey
2021-03-23 22:49                   ` Dylan Reid
2021-03-26  8:07                     ` Takashi Iwai
2021-03-19 18:11     ` Jaroslav Kysela
2021-03-19 22:13       ` Hans de Goede
2021-03-30 15:49 ` [PATCH v4 0/6] ALSA: control - add generic LED API Takashi Iwai

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=e9ff74df-4ca1-390b-b906-81019c0cf66d@perex.cz \
    --to=perex@perex.cz \
    --cc=Perry.Yuan@dell.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cujomalainey@google.com \
    --cc=dgreid@google.com \
    --cc=hdegoede@redhat.com \
    --cc=tiwai@suse.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.