| Age | Commit message (Collapse) | Author |
|---|
|
CONFIG_SND_SEQ_UMP_CLIENT is a Kconfig for a sequencer client
corresponding to the UMP rawmidi, while we have another major knob
CONFIG_SND_SEQ_UMP that specifies whether the sequencer core supports
UMP packets or not. Strictly speaking both of them are independent,
but practically seen, it makes no sense to enable
CONFIG_SND_SEQ_UMP_CLIENT without UMP support itself.
This patch makes such an implicit dependency clearer. Now
CONFIG_SND_SEQ_UMP_CLIENT depends on both CONFIG_SND_UMP and
CONFIG_SND_SEQ_UMP. Meanwhile, CONFIG_SND_SEQ_UMP is enabled as
default when CONFIG_SND_UMP is set.
Fixes: 81fd444aa371 ("ALSA: seq: Bind UMP device")
Link: https://patch.msgid.link/20250101125548.25961-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
'def_tristate' is a shorthand for 'default' + 'tristate'.
Another 'tristate' is redundant.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20240215135304.1909431-1-masahiroy@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch introduces a new ALSA sequencer client for the kernel UMP
object, snd-seq-ump-client. It's a UMP version of snd-seq-midi
driver, while this driver creates a sequencer client per UMP endpoint
which contains (fixed) 16 ports.
The UMP rawmidi device is opened in APPEND mode for output, so that
multiple sequencer clients can share the same UMP endpoint, as well as
the legacy UMP rawmidi devices that are opened in APPEND mode, too.
For input, on the other hand, the incoming data is processed on the
fly in the dedicated hook, hence it doesn't open a rawmidi device.
The UMP packet group is updated upon delivery depending on the target
sequencer port (which corresponds to the actual UMP group).
Each sequencer port sets a new port type bit,
SNDRV_SEQ_PORT_TYPE_MIDI_UMP, in addition to the other standard
types for MIDI.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-33-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch enables the automatic conversion of UMP events from/to the
legacy ALSA sequencer MIDI events. Also, as UMP itself has two
different modes (MIDI 1.0 and MIDI 2.0), yet another converters
between them are needed, too. Namely, we have conversions between the
legacy and UMP like:
- seq legacy event -> seq UMP MIDI 1.0 event
- seq legacy event -> seq UMP MIDI 2.0 event
- seq UMP MIDI 1.0 event -> seq legacy event
- seq UMP MIDI 2.0 event -> seq legacy event
and the conversions between UMP MIDI 1.0 and 2.0 clients like:
- seq UMP MIDI 1.0 event -> seq UMP MIDI 2.0 event
- seq UMP MIDI 2.0 event -> seq UMP MIDI 1.0 event
The translation is per best-effort; some MIDI 2.0 specific events are
ignored when translated to MIDI 1.0.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-31-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Starting from this commit, we add the basic support of UMP (Universal
MIDI Packet) events on ALSA sequencer infrastructure. The biggest
change here is that, for transferring UMP packets that are up to 128
bits, we extend the data payload of ALSA sequencer event record when
the client is declared to support for the new UMP events.
A new event flag bit, SNDRV_SEQ_EVENT_UMP, is defined and it shall be
set for the UMP packet events that have the larger payload of 128
bits, defined as struct snd_seq_ump_event.
For controlling the UMP feature enablement in kernel, a new Kconfig,
CONFIG_SND_SEQ_UMP is introduced. The extended event for UMP is
available only when this Kconfig item is set. Similarly, the size of
the internal snd_seq_event_cell also increases (in 4 bytes) when the
Kconfig item is set. (But the size increase is effective only for
32bit architectures; 64bit archs already have padding there.)
Overall, when CONFIG_SND_SEQ_UMP isn't set, there is no change in the
event and cell, keeping the old sizes.
For applications that want to access the UMP packets, first of all, a
sequencer client has to declare the user-protocol to match with the
latest one via the new SNDRV_SEQ_IOCTL_USER_PVERSION; otherwise it's
treated as if a legacy client without UMP support.
Then the client can switch to the new UMP mode (MIDI 1.0 or MIDI 2.0)
with a new field, midi_version, in snd_seq_client_info. When switched
to UMP mode (midi_version = 1 or 2), the client can write the UMP
events with SNDRV_SEQ_EVENT_UMP flag. For reads, the alignment size
is changed from snd_seq_event (28 bytes) to snd_seq_ump_event (32
bytes). When a UMP sequencer event is delivered to a legacy sequencer
client, it's ignored or handled as an error.
Conceptually, ALSA sequencer client and port correspond to the UMP
Endpoint and Group, respectively; each client may have multiple ports
and each port has the fixed number (16) of channels, total up to 256
channels.
As of this commit, ALSA sequencer core just sends and receives the UMP
events as-is from/to clients. The automatic conversions between the
legacy events and the new UMP events will be implemented in a later
patch.
Along with this commit, bump the sequencer protocol version to 1.0.3.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The commit 0181307abc1d ("ALSA: seq: Reorganize kconfig and build")
rewrote the dependency of each sequencer module in a standard way, but
there was one change applied mistakenly: CONFIG_SND_SEQ_MIDI isn't
enabled properly by CONFIG_SND_RAWMIDI. I seem to have changed the
wrong one instead, CONFIG_SND_SEQ_MIDI_EMUL, which is eventually
reverse-selected by CONFIG_SND_SEQ_MIDI itself. This ended up the
lack of snd-seq-midi module as reported below.
The fix is to put def_tristate properly to CONFIG_SND_SEQ_MIDI instead
of *_MIDI_EMUL entry.
Fixes: 0181307abc1d ("ALSA: seq: Reorganize kconfig and build")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196633
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
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>
|
|
This is a slightly intensive rewrite of Kconfig and Makefile about
ALSA sequencer stuff.
The first major change is that the kconfig items for the sequencer are
moved to sound/core/seq/Kconfig. OK, that's easy.
The substantial change is that, instead of hackish top-level module
selection in Makefile, we define a Kconfig item for each sequencer
module. The driver that requires such sequencer components select
exclusively the kconfig items. This is more straightforward and
standard way.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Instead of mangling the CONFIG_* variables in the makefiles over and
over, set a few helper variables in Kconfig.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
