2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 22:20:36 +00:00
|
|
|
# ALSA soundcard-configuration
|
|
|
|
|
config SND_TIMER
|
|
|
|
|
tristate
|
|
|
|
|
|
|
|
|
|
config SND_PCM
|
|
|
|
|
tristate
|
2015-10-16 09:57:46 +00:00
|
|
|
select SND_TIMER if SND_PCM_TIMER
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-05-09 10:26:42 +00:00
|
|
|
config SND_PCM_ELD
|
|
|
|
|
bool
|
|
|
|
|
|
2015-05-09 10:26:47 +00:00
|
|
|
config SND_PCM_IEC958
|
|
|
|
|
bool
|
|
|
|
|
|
2013-08-12 08:42:37 +00:00
|
|
|
config SND_DMAENGINE_PCM
|
2013-08-15 14:03:52 +00:00
|
|
|
tristate
|
2013-08-12 08:42:37 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
config SND_HWDEP
|
|
|
|
|
tristate
|
|
|
|
|
|
ALSA: seq: Allow the modular sequencer registration
Many drivers bind the sequencer stuff in off-load by another driver
module, so that it's loaded only on demand. In the current code, this
mechanism doesn't work when the driver is built-in while the sequencer
is module. We check with IS_REACHABLE() and enable only when the
sequencer is in the same level of build.
However, this is basically a overshoot. The binder code
(snd-seq-device) is an individual module from the sequencer core
(snd-seq), and we just have to make the former a built-in while
keeping the latter a module for allowing the scenario like the above.
This patch achieves that by rewriting Kconfig slightly. Now, a driver
that provides the manual sequencer device binding should select
CONFIG_SND_SEQ_DEVICE in a way as
select SND_SEQ_DEVICE if SND_SEQUENCER != n
Note that the "!=n" is needed here to avoid the influence of the
sequencer core is module while the driver is built-in.
Also, since rawmidi.o may be linked with snd_seq_device.o when
built-in, we have to shuffle the code to make the linker happy.
(the kernel linker isn't smart enough yet to handle such a case.)
That is, snd_seq_device.c is moved to sound/core from sound/core/seq,
as well as Makefile.
Last but not least, the patch replaces the code using IS_REACHABLE()
with IS_ENABLED(), since now the condition meets always when enabled.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-09 13:11:58 +00:00
|
|
|
config SND_SEQ_DEVICE
|
|
|
|
|
tristate
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
config SND_RAWMIDI
|
|
|
|
|
tristate
|
ALSA: seq: Allow the modular sequencer registration
Many drivers bind the sequencer stuff in off-load by another driver
module, so that it's loaded only on demand. In the current code, this
mechanism doesn't work when the driver is built-in while the sequencer
is module. We check with IS_REACHABLE() and enable only when the
sequencer is in the same level of build.
However, this is basically a overshoot. The binder code
(snd-seq-device) is an individual module from the sequencer core
(snd-seq), and we just have to make the former a built-in while
keeping the latter a module for allowing the scenario like the above.
This patch achieves that by rewriting Kconfig slightly. Now, a driver
that provides the manual sequencer device binding should select
CONFIG_SND_SEQ_DEVICE in a way as
select SND_SEQ_DEVICE if SND_SEQUENCER != n
Note that the "!=n" is needed here to avoid the influence of the
sequencer core is module while the driver is built-in.
Also, since rawmidi.o may be linked with snd_seq_device.o when
built-in, we have to shuffle the code to make the linker happy.
(the kernel linker isn't smart enough yet to handle such a case.)
That is, snd_seq_device.c is moved to sound/core from sound/core/seq,
as well as Makefile.
Last but not least, the patch replaces the code using IS_REACHABLE()
with IS_ENABLED(), since now the condition meets always when enabled.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-09 13:11:58 +00:00
|
|
|
select SND_SEQ_DEVICE if SND_SEQUENCER != n
|
2005-04-16 22:20:36 +00:00
|
|
|
|
ALSA: rawmidi: UMP support
This patch adds the support helpers for UMP (Universal MIDI Packet) in
ALSA core.
The basic design is that a rawmidi instance is assigned to each UMP
Endpoint. A UMP Endpoint provides a UMP stream, typically
bidirectional (but can be also uni-directional, too), which may hold
up to 16 UMP Groups, where each UMP (input/output) Group corresponds
to the traditional MIDI I/O Endpoint.
Additionally, the ALSA UMP abstraction provides the multiple UMP
Blocks that can be assigned to each UMP Endpoint. A UMP Block is a
metadata to hold the UMP Group clusters, and can represent the
functions assigned to each UMP Group. A typical implementation of UMP
Block is the Group Terminal Blocks of USB MIDI 2.0 specification.
For distinguishing from the legacy byte-stream MIDI device, a new
device "umpC*D*" will be created, instead of the standard (MIDI 1.0)
devices "midiC*D*". The UMP instance can be identified by the new
rawmidi info bit SNDRV_RAWMIDI_INFO_UMP, too.
A UMP rawmidi device reads/writes only in 4-bytes words alignment,
stored in CPU native endianness.
The transmit and receive functions take care of the input/out data
alignment, and may return zero or aligned size, and the params ioctl
may return -EINVAL when the given input/output buffer size isn't
aligned.
A few new UMP-specific ioctls are added for obtaining the new UMP
endpoint and block information.
As of this commit, no ALSA sequencer instance is attached to UMP
devices yet. They will be supported by later patches.
Along with those changes, the protocol version for rawmidi is bumped
to 2.0.3.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 07:53:24 +00:00
|
|
|
config SND_UMP
|
|
|
|
|
tristate
|
|
|
|
|
select SND_RAWMIDI
|
|
|
|
|
|
2023-05-23 07:53:35 +00:00
|
|
|
config SND_UMP_LEGACY_RAWMIDI
|
|
|
|
|
bool "Legacy raw MIDI support for UMP streams"
|
|
|
|
|
depends on SND_UMP
|
|
|
|
|
help
|
|
|
|
|
This option enables the legacy raw MIDI support for UMP streams.
|
|
|
|
|
When this option is set, an additional rawmidi device for the
|
|
|
|
|
legacy MIDI 1.0 byte streams is created for each UMP Endpoint.
|
|
|
|
|
The device contains 16 substreams corresponding to UMP groups.
|
|
|
|
|
|
2012-01-13 08:53:53 +00:00
|
|
|
config SND_COMPRESS_OFFLOAD
|
|
|
|
|
tristate
|
|
|
|
|
|
2008-07-28 18:05:36 +00:00
|
|
|
config SND_JACK
|
|
|
|
|
bool
|
|
|
|
|
|
2016-02-17 08:44:25 +00:00
|
|
|
# enable input device support in jack layer
|
|
|
|
|
config SND_JACK_INPUT_DEV
|
|
|
|
|
bool
|
|
|
|
|
depends on SND_JACK
|
|
|
|
|
default y if INPUT=y || INPUT=SND
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
config SND_OSSEMUL
|
2017-06-09 11:56:05 +00:00
|
|
|
bool "Enable OSS Emulation"
|
2008-08-28 14:42:51 +00:00
|
|
|
select SOUND_OSS_CORE
|
2017-06-09 11:56:05 +00:00
|
|
|
help
|
|
|
|
|
This option enables the build of OSS emulation layer.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
config SND_MIXER_OSS
|
|
|
|
|
tristate "OSS Mixer API"
|
2017-06-09 11:56:05 +00:00
|
|
|
depends on SND_OSSEMUL
|
2005-04-16 22:20:36 +00:00
|
|
|
help
|
|
|
|
|
To enable OSS mixer API emulation (/dev/mixer*), say Y here
|
2018-05-08 18:14:57 +00:00
|
|
|
and read <file:Documentation/sound/designs/oss-emulation.rst>.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
Many programs still use the OSS API, so say Y.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called snd-mixer-oss.
|
|
|
|
|
|
|
|
|
|
config SND_PCM_OSS
|
|
|
|
|
tristate "OSS PCM (digital audio) API"
|
2017-06-09 11:56:05 +00:00
|
|
|
depends on SND_OSSEMUL
|
2005-04-16 22:20:36 +00:00
|
|
|
select SND_PCM
|
|
|
|
|
help
|
|
|
|
|
To enable OSS digital audio (PCM) emulation (/dev/dsp*), say Y
|
2018-05-08 18:14:57 +00:00
|
|
|
here and read <file:Documentation/sound/designs/oss-emulation.rst>.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
Many programs still use the OSS API, so say Y.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called snd-pcm-oss.
|
|
|
|
|
|
2006-01-13 08:12:11 +00:00
|
|
|
config SND_PCM_OSS_PLUGINS
|
|
|
|
|
bool "OSS PCM (digital audio) API - Include plugin system"
|
|
|
|
|
depends on SND_PCM_OSS
|
2019-10-04 14:49:31 +00:00
|
|
|
default y
|
2006-01-13 08:12:11 +00:00
|
|
|
help
|
2019-10-04 14:49:31 +00:00
|
|
|
If you disable this option, the ALSA's OSS PCM API will not
|
|
|
|
|
support conversion of channels, formats and rates. It will
|
|
|
|
|
behave like most of new OSS/Free drivers in 2.4/2.6 kernels.
|
2006-01-13 08:12:11 +00:00
|
|
|
|
2015-10-16 09:57:46 +00:00
|
|
|
config SND_PCM_TIMER
|
|
|
|
|
bool "PCM timer interface" if EXPERT
|
|
|
|
|
default y
|
|
|
|
|
help
|
2016-01-28 02:04:10 +00:00
|
|
|
If you disable this option, pcm timer will be unavailable, so
|
|
|
|
|
those stubs that use pcm timer (e.g. dmix, dsnoop & co) may work
|
2022-03-18 01:52:01 +00:00
|
|
|
incorrectly.
|
2015-10-16 09:57:46 +00:00
|
|
|
|
2016-01-28 02:04:10 +00:00
|
|
|
For some embedded devices, we may disable it to reduce memory
|
2015-10-16 09:57:46 +00:00
|
|
|
footprint, about 20KB on x86_64 platform.
|
|
|
|
|
|
2008-10-24 16:16:50 +00:00
|
|
|
config SND_HRTIMER
|
|
|
|
|
tristate "HR-timer backend support"
|
|
|
|
|
depends on HIGH_RES_TIMERS
|
|
|
|
|
select SND_TIMER
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable HR-timer backend for ALSA timer. ALSA uses
|
|
|
|
|
the hrtimer as a precise timing source. The ALSA sequencer code
|
|
|
|
|
also can use this timing source.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called snd-hrtimer.
|
|
|
|
|
|
2005-11-20 13:07:47 +00:00
|
|
|
config SND_DYNAMIC_MINORS
|
2006-06-27 06:41:26 +00:00
|
|
|
bool "Dynamic device file minor numbers"
|
2005-11-20 13:07:47 +00:00
|
|
|
help
|
|
|
|
|
If you say Y here, the minor numbers of ALSA device files in
|
|
|
|
|
/dev/snd/ are allocated dynamically. This allows you to have
|
|
|
|
|
more than 8 sound cards, but requires a dynamic device file
|
|
|
|
|
system like udev.
|
|
|
|
|
|
|
|
|
|
If you are unsure about this, say N here.
|
|
|
|
|
|
ALSA: Add kconfig to specify the max card numbers
Currently ALSA supports up to 32 card instances when the dynamic minor
is used. While 32 cards are usually big enough for normal use cases,
there are sometimes weird requirements with more card support.
Actually, this limitation, 32, comes from the index option, where you
can pass the bit mask to assign the card. Other than that, we can
actually give more cards up to the minor number limits (currently 256,
which can be extended more, too).
This patch adds a new Kconfig to specify the max card numbers, and
changes a few places to accept more than 32 cards.
The only incompatibility with high card numbers would be the handling
of index option. The index option can be still used to pass the
bitmask for card assignments, but this works only up to 32 slots.
More than 32, no bitmask style option is available but only a single
slot can be specified via index option.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-05-15 06:46:39 +00:00
|
|
|
config SND_MAX_CARDS
|
|
|
|
|
int "Max number of sound cards"
|
|
|
|
|
range 4 256
|
|
|
|
|
default 32
|
|
|
|
|
depends on SND_DYNAMIC_MINORS
|
|
|
|
|
help
|
|
|
|
|
Specify the max number of sound cards that can be assigned
|
|
|
|
|
on a single machine.
|
|
|
|
|
|
2005-12-01 09:51:58 +00:00
|
|
|
config SND_SUPPORT_OLD_API
|
|
|
|
|
bool "Support old ALSA API"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say Y here to support the obsolete ALSA PCM API (ver.0.9.0 rc3
|
|
|
|
|
or older).
|
|
|
|
|
|
2015-05-27 11:45:44 +00:00
|
|
|
config SND_PROC_FS
|
2019-10-04 14:49:31 +00:00
|
|
|
bool "Sound Proc FS Support" if EXPERT
|
|
|
|
|
depends on PROC_FS
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say 'N' to disable Sound proc FS, which may reduce code size about
|
|
|
|
|
9KB on x86_64 platform.
|
|
|
|
|
If unsure say Y.
|
2015-05-27 11:45:44 +00:00
|
|
|
|
2006-01-13 08:12:11 +00:00
|
|
|
config SND_VERBOSE_PROCFS
|
|
|
|
|
bool "Verbose procfs contents"
|
2015-05-27 11:45:44 +00:00
|
|
|
depends on SND_PROC_FS
|
2006-01-13 08:12:11 +00:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say Y here to include code for verbose procfs contents (provides
|
2019-10-04 14:49:31 +00:00
|
|
|
useful information to developers when a problem occurs). On the
|
|
|
|
|
other side, it makes the ALSA subsystem larger.
|
2006-01-13 08:12:11 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
config SND_VERBOSE_PRINTK
|
|
|
|
|
bool "Verbose printk"
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable verbose log messages. These messages
|
|
|
|
|
will help to identify source file and position containing
|
|
|
|
|
printed messages.
|
|
|
|
|
|
|
|
|
|
You don't need this unless you're debugging ALSA.
|
|
|
|
|
|
ALSA: control: Use xarray for faster lookups
The control elements are managed in a single linked list and we
traverse the whole list for matching each numid or ctl id per every
inquiry of a control element. This is OK-ish for a small number of
elements but obviously it doesn't scale. Especially the matching with
the ctl id takes time because it checks each field of the snd_ctl_id
element, e.g. the name string is matched with strcmp().
This patch adds the hash tables with Xarray for improving the lookup
speed of a control element. There are two xarray tables added to the
card; one for numid and another for ctl id. For the numid, we use the
numid as the index, while for the ctl id, we calculate a hash key.
The lookup is done via a single xa_load() execution. As long as the
given control element is found on the Xarray table, that's fine, we
can give back a quick lookup result. The problem is when no entry
hits on the table, and for this case, we have a slight optimization.
Namely, the driver checks whether we had a collision on Xarray table,
and do a fallback search (linear lookup of the full entries) only if a
hash key collision happened beforehand.
So, in theory, the inquiry for a non-existing element might take still
time even with this patch in a worst case, but this must be pretty
rare.
The feature is enabled via CONFIG_SND_CTL_FAST_LOOKUP, which is turned
on as default. For simplicity, the option can be turned off only when
CONFIG_EXPERT is set ("You are expert? Then you manage 1000 knobs").
Link: https://lore.kernel.org/r/20211028130027.18764-1-tiwai@suse.de
Link: https://lore.kernel.org/r/20220609180504.775-1-tiwai@suse.de
Link: https://lore.kernel.org/all/cover.1653813866.git.quic_rbankapu@quicinc.com/
Link: https://lore.kernel.org/r/20220610064537.18660-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-10 06:45:37 +00:00
|
|
|
config SND_CTL_FAST_LOOKUP
|
|
|
|
|
bool "Fast lookup of control elements" if EXPERT
|
|
|
|
|
default y
|
|
|
|
|
select XARRAY_MULTI
|
|
|
|
|
help
|
|
|
|
|
This option enables the faster lookup of control elements.
|
|
|
|
|
It will consume more memory because of the additional Xarray.
|
|
|
|
|
If you want to choose the memory footprint over the performance
|
|
|
|
|
inevitably, turn this off.
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
config SND_DEBUG
|
|
|
|
|
bool "Debug"
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable ALSA debug code.
|
|
|
|
|
|
2008-05-20 10:15:15 +00:00
|
|
|
config SND_DEBUG_VERBOSE
|
|
|
|
|
bool "More verbose debug"
|
2005-04-16 22:20:36 +00:00
|
|
|
depends on SND_DEBUG
|
|
|
|
|
help
|
2008-05-20 10:15:15 +00:00
|
|
|
Say Y here to enable extra-verbose debugging messages.
|
2019-10-04 14:49:31 +00:00
|
|
|
|
2008-05-20 10:15:15 +00:00
|
|
|
Let me repeat: it enables EXTRA-VERBOSE DEBUGGING messages.
|
|
|
|
|
So, say Y only if you are ready to be annoyed.
|
2006-04-24 19:57:16 +00:00
|
|
|
|
|
|
|
|
config SND_PCM_XRUN_DEBUG
|
|
|
|
|
bool "Enable PCM ring buffer overrun/underrun debugging"
|
|
|
|
|
default n
|
2006-04-25 10:56:04 +00:00
|
|
|
depends on SND_DEBUG && SND_VERBOSE_PROCFS
|
2006-04-24 19:57:16 +00:00
|
|
|
help
|
|
|
|
|
Say Y to enable the PCM ring buffer overrun/underrun debugging.
|
|
|
|
|
It is usually not required, but if you have trouble with
|
|
|
|
|
sound clicking when system is loaded, it may help to determine
|
|
|
|
|
the process or driver which causes the scheduling gaps.
|
2008-02-18 12:03:13 +00:00
|
|
|
|
2022-06-09 12:02:19 +00:00
|
|
|
config SND_CTL_INPUT_VALIDATION
|
|
|
|
|
bool "Validate input data to control API"
|
|
|
|
|
help
|
|
|
|
|
Say Y to enable the additional validation for the input data to
|
|
|
|
|
each control element, including the value range checks.
|
|
|
|
|
An error is returned from ALSA core for invalid inputs without
|
|
|
|
|
passing to the driver. This is a kind of hardening for drivers
|
|
|
|
|
that have no proper error checks, at the cost of a slight
|
|
|
|
|
performance overhead.
|
|
|
|
|
|
2022-06-09 12:02:17 +00:00
|
|
|
config SND_CTL_DEBUG
|
|
|
|
|
bool "Enable debugging feature for control API"
|
ALSA: control: Add verification for kctl accesses
The current implementation of ALSA control API fully relies on the
callbacks of each driver, and there is no verification of the values
passed via API. This patch is an attempt to improve the situation
slightly by adding the validation code for the values stored via info
and get callbacks.
The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION. It depends
on CONFIG_SND_DEBUG and off as default since the validation would
require a slight overhead including the additional call of info
callback at each get callback invocation.
When this config is enabled, the values stored by each info callback
invocation are verified, namely:
- Whether the info type is valid
- Whether the number of enum items is non-zero
- Whether the given info count is within the allowed boundary
Similarly, the values stored at each get callback are verified as
well:
- Whether the values are within the given range
- Whether the values are aligned with the given step
- Whether any further changes are seen in the data array over the
given info count
The last point helps identifying a possibly invalid data type access,
typically a case where the info callback declares the type being
SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store
the values in value.integer.value[] array.
When a validation fails, the ALSA core logs an error message including
the device and the control ID, and the API call also returns an
error. So, with the new validation turned on, the driver behavior
difference may be visible on user-space, too -- it's intentional,
though, so that we can catch an error more clearly.
The patch also introduces a new ctl access type,
SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK. A driver may pass this flag with
other access bits to indicate that the ctl element won't be verified.
It's useful when a driver code is specially written to access the data
greater than info->count size by some reason. For example, this flag
is actually set now in HD-audio HDMI codec driver which needs to clear
the data array in the case of the disconnected monitor.
Also, the PCM channel-map helper code is slightly modified to avoid
the false-positive hit by this validation code, too.
Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-04 08:35:56 +00:00
|
|
|
depends on SND_DEBUG
|
|
|
|
|
help
|
2022-06-09 12:02:17 +00:00
|
|
|
Say Y to enable the debugging feature for ALSA control API.
|
|
|
|
|
It performs the additional sanity-checks for each control element
|
|
|
|
|
read access, such as whether the values returned from the driver
|
|
|
|
|
are in the proper ranges or the check of the invalid access at
|
|
|
|
|
out-of-array areas. The error is printed when the driver gives
|
|
|
|
|
such unexpected values.
|
|
|
|
|
When you develop a driver that deals with control elements, it's
|
|
|
|
|
strongly recommended to try this one once and verify whether you see
|
|
|
|
|
any relevant errors or not.
|
ALSA: control: Add verification for kctl accesses
The current implementation of ALSA control API fully relies on the
callbacks of each driver, and there is no verification of the values
passed via API. This patch is an attempt to improve the situation
slightly by adding the validation code for the values stored via info
and get callbacks.
The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION. It depends
on CONFIG_SND_DEBUG and off as default since the validation would
require a slight overhead including the additional call of info
callback at each get callback invocation.
When this config is enabled, the values stored by each info callback
invocation are verified, namely:
- Whether the info type is valid
- Whether the number of enum items is non-zero
- Whether the given info count is within the allowed boundary
Similarly, the values stored at each get callback are verified as
well:
- Whether the values are within the given range
- Whether the values are aligned with the given step
- Whether any further changes are seen in the data array over the
given info count
The last point helps identifying a possibly invalid data type access,
typically a case where the info callback declares the type being
SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store
the values in value.integer.value[] array.
When a validation fails, the ALSA core logs an error message including
the device and the control ID, and the API call also returns an
error. So, with the new validation turned on, the driver behavior
difference may be visible on user-space, too -- it's intentional,
though, so that we can catch an error more clearly.
The patch also introduces a new ctl access type,
SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK. A driver may pass this flag with
other access bits to indicate that the ctl element won't be verified.
It's useful when a driver code is specially written to access the data
greater than info->count size by some reason. For example, this flag
is actually set now in HD-audio HDMI codec driver which needs to clear
the data array in the case of the disconnected monitor.
Also, the PCM channel-map helper code is slightly modified to avoid
the false-positive hit by this validation code, too.
Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-04 08:35:56 +00:00
|
|
|
|
ALSA: jack: implement software jack injection via debugfs
This change adds audio jack injection feature through debugfs, with
this feature, we could validate alsa userspace changes by injecting
plugin or plugout events to the non-phantom audio jacks.
With this change, the sound core will build the folders
$debugfs_mount_dir/sound/cardN if SND_DEBUG and DEBUG_FS are enabled.
And if users also enable the SND_JACK_INJECTION_DEBUG, the jack
injection nodes will be built in the folder cardN like below:
$tree $debugfs_mount_dir/sound
$debugfs_mount_dir/sound
├── card0
│ ├── HDMI_DP_pcm_10_Jack
│ │ ├── jackin_inject
│ │ ├── kctl_id
│ │ ├── mask_bits
│ │ ├── status
│ │ ├── sw_inject_enable
│ │ └── type
...
│ └── HDMI_DP_pcm_9_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── card1
├── HDMI_DP_pcm_5_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
...
├── Headphone_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── Headset_Mic_Jack
├── jackin_inject
├── kctl_id
├── mask_bits
├── status
├── sw_inject_enable
└── type
The nodes kctl_id, mask_bits, status and type are read-only, users
could check jack or jack_kctl's information through them.
The nodes sw_inject_enable and jackin_inject are directly used for
injection. The sw_inject_enable is read-write, users could check if
software injection is enabled or not on this jack, and users could
echo 1 or 0 to enable or disable software injection on this jack. Once
the injection is enabled, the jack will not change by hardware events
anymore, once the injection is disabled, the jack will restore the
last reported hardware events to the jack. The jackin_inject is
write-only, if the injection is enabled, users could echo 1 or 0 to
this node to inject plugin or plugout events to this jack.
For the detailed usage information on these nodes, please refer to
Documentation/sound/designs/jack-injection.rst.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210127085639.74954-2-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-01-27 08:56:39 +00:00
|
|
|
config SND_JACK_INJECTION_DEBUG
|
|
|
|
|
bool "Sound jack injection interface via debugfs"
|
|
|
|
|
depends on SND_JACK && SND_DEBUG && DEBUG_FS
|
|
|
|
|
help
|
|
|
|
|
This option can be used to enable or disable sound jack
|
|
|
|
|
software injection.
|
|
|
|
|
Say Y if you are debugging via jack injection interface.
|
|
|
|
|
If unsure select "N".
|
|
|
|
|
|
2008-02-18 12:03:13 +00:00
|
|
|
config SND_VMASTER
|
|
|
|
|
bool
|
2009-05-26 15:07:52 +00:00
|
|
|
|
2008-06-17 14:39:06 +00:00
|
|
|
config SND_DMA_SGBUF
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on X86
|
|
|
|
|
|
2021-03-17 17:29:42 +00:00
|
|
|
config SND_CTL_LED
|
|
|
|
|
tristate
|
|
|
|
|
select NEW_LEDS if SND_CTL_LED
|
|
|
|
|
select LEDS_TRIGGERS if SND_CTL_LED
|
|
|
|
|
select LEDS_TRIGGER_AUDIO if SND_CTL_LED
|
|
|
|
|
|
2009-05-26 15:07:52 +00:00
|
|
|
source "sound/core/seq/Kconfig"
|
