| Age | Commit message (Collapse) | Author |
|---|
|
In the original change, rawmidi_info.tied_device showed -1 for the
unknown or untied device. But this would require the user-space to
check the protocol version and judge the value conditionally, which
is rather error-prone.
Instead, set the tied_device = 0 to be default as unknown, and
indicate the real device with the offset 1, for achieving more
backward compatibility.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Link: https://patch.msgid.link/20250114104711.19197-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
So far we notify the sequencer client and port changes upon UMP FB
changes, but those aren't really corresponding to the UMP updates.
e.g. when a FB info gets updated, it's not notified but done only when
some of sequencer port attribute is changed. This is no ideal
behavior.
This patch adds the two new sequencer event types for notifying the
UMP EP and FB changes via the announce port. The new event takes
snd_seq_ev_ump_notify type data, which is compatible with
snd_seq_addr (where the port number is replaced with the block
number).
The events are sent when the EP and FB info gets updated explicitly
via ioctl, or the backend UMP receives the corresponding UMP
messages.
The sequencer protocol version is bumped to 1.0.5 along with it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-9-tiwai@suse.de
|
|
The rawmidi name string should be updated dynamically when the device
receives the UMP EP name update, too. Both the core and legacy
rawmidi names are updated.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-7-tiwai@suse.de
|
|
The UMP helper didn't set up the rawmidi name string by itself but
left it to the driver. But since the only user (USB MIDI2 driver)
picks up the UMP info name string to the rawmidi name as default, it's
better to set up in the UMP core side.
Meanwhile, UMP receives the EP name string from the device, and it
might contain garbage letters. We should purify the string to be
usable for the kernel as done previously for UMP Group names.
This implements the copy of the UMP info name string into the rawmidi
name at the creation of UMP EP object in a safe way to strip the
non-ASCII or non-printable characters. Also, change the reference
from the legacy rawmidi and other places to rawmidi name field instead
of ump info; this assures the sane strings.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-6-tiwai@suse.de
|
|
The UMP group names are referred as the corresponding sequencer port
names, hence they should be proper ASCII strings. OTOH, the UMP group
names are composed from the UMP FB strings that are received from the
device; i.e. a device may give some bogus letters and we can't trust
them fully.
To assure that the group names consist of the proper ASCII strings,
replace the normal string copy and append operations with special ones
that strip the non-printable letters.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-5-tiwai@suse.de
|
|
The UMP legacy rawmidi may turn on/off the substream dynamically
depending on the UMP Function Block information. So far, there was no
direct way to know whether the substream is disabled (inactive) or
not; at most one can take a look at the substream name string or try
to open and get -ENODEV.
This patch extends the rawmidi info ioctl to show the current inactive
state of the given substream. When the selected substream is
inactive, info flags field contains the new bit flag
SNDRV_RAWMIDI_INFO_STREAM_INACTIVE.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-3-tiwai@suse.de
|
|
The UMP legacy rawmidi is derived from the UMP rawmidi, but currently
there is no way to know which device is involved in other side.
This patch extends the rawmidi info ioctl to show the tied device
number. As default it stores -1, indicating that no tied device.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-2-tiwai@suse.de
|
|
This reverts commit c2d188e137e77294323132a760a4608321a36a70.
Although it's fine to filter the invalid UMP groups at the first probe
time, this will become a problem when UMP groups are updated and
(re-)activated. Then there is no way to re-add the substreams
properly for the legacy rawmidi, and the new active groups will be
still invisible.
So let's revert the change. This will move back to showing the full
16 groups, but it's better than forever lost.
Link: https://patch.msgid.link/20241230114023.3787-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recent change for the legacy substream name update brought a
compile warning for some compilers due to the nature of snprintf().
Use scnprintf() to shut up the warning since the truncation is
intentional.
Fixes: e29e504e7890 ("ALSA: ump: Indicate the inactive group in legacy substream names")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202411300103.FrGuTAYp-lkp@intel.com/
Link: https://patch.msgid.link/20241130090009.19849-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The legacy rawmidi substreams should be updated when UMP FB Info or
UMP FB Name are received, too.
Link: https://patch.msgid.link/20241129094546.32119-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Since the legacy rawmidi has no proper way to know the inactive group,
indicate it in the rawmidi substream names with "[Inactive]" suffix
when the corresponding UMP group is inactive.
Link: https://patch.msgid.link/20241129094546.32119-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a UMP Group is inactive, we shouldn't allow users to access it
via the legacy MIDI access. Add the group active flag check and
return -ENODEV if it's inactive.
Link: https://patch.msgid.link/20241129094546.32119-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The m1.0 field of UMP Function Block info specifies whether the given
FB is a MIDI 1.0 port or not. When implementing the UMP support on
Linux, I somehow interpreted as if it were bit flags, but the field is
actually an enumeration from 0 to 2, where 2 means MIDI 1.0 *and* low
speed.
This patch corrects the interpretation and sets the right bit flags
depending on the m1.0 field of FB Info. This effectively fixes the
missing detection of MIDI 1.0 FB when m1.0 is 2.
Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing")
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20241127070059.8099-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The format specifier of "unsigned int" in snprintf()
should be "%u", not "%d".
Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com>
Link: https://patch.msgid.link/20241114075822.41614-1-zhangjiao2@cmss.chinamobile.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The unsigned expression 'blk' will never be negative, so remove the
unnecessary check.
Signed-off-by: Luo Yifan <luoyifan@cmss.chinamobile.com>
Link: https://patch.msgid.link/20241108032702.217168-1-luoyifan@cmss.chinamobile.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The legacy rawmidi tries to enumerate all possible UMP groups
belonging to the UMP endpoint. But currently it shows all 16 ports
when the UMP endpoint is configured with static blocks, although most
of them may be unused.
There was already a fix for the sequencer client side to ignore such
groups in the commit 3bfd7c0ba184 ("ALSA: seq: ump: Skip useless ports
for static blocks"), and this commit is a similar fix for UMP
rawmidi devices; it adds simply the check for the validity of each
group that has been already parsed. (Note that the group info was
moved to snd_ump_endpoint.groups[] by the commit 0642a3c5cacc0321c755
("ALSA: ump: Update substream name from assigned FB names")).
Link: https://patch.msgid.link/20241104100735.16127-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Use %*ph format to print small buffer as hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20240911195039.2885979-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a FB is created from a GTB instead of UMP FB Info inquiry, we
missed the update of the corresponding UMP Group attributes.
Export the call of updater and let it be called from the USB driver.
Fixes: 0642a3c5cacc ("ALSA: ump: Update substream name from assigned FB names")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240807092303.1935-5-tiwai@suse.de
|
|
When the protocol capability bits are changed via Endpoint Info update
notification, we should check the validity of the current protocol and
reset it if needed, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240807092303.1935-2-tiwai@suse.de
|
|
The UMP v1.1 spec says in the section 6.2.1:
"If a UMP Endpoint declares MIDI 2.0 Protocol but a Function Block
represents a MIDI 1.0 connection, then may optionally be used for
messages to/from that Function Block."
It implies that the driver can (and should) keep MIDI 1.0 CVM
exceptionally for those FBs even if UMP Endpoint is running in MIDI
2.0 protocol, and the current driver lacks of it.
This patch extends the sequencer port info to indicate a MIDI 1.0
port, and tries to send/receive MIDI 1.0 CVM as is when this port is
the source or sink. The sequencer port flag is set by the driver at
parsing FBs and GTBs although application can set it to its own
user-space clients, too.
Link: https://patch.msgid.link/20240806070024.14301-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We had a nice name scheme in ALSA sequencer UMP binding for each
sequencer port referring to each assigned Function Block name, while
the legacy rawmidi refers only to the UMP Endpoint name. It's better
to align both.
This patch moves the UMP Group attribute update functions into the
core UMP code from the sequencer binding code, and improve the
substream name of the legacy rawmidi.
Link: https://patch.msgid.link/20240729141315.18253-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a Function Block declares it being a legacy MIDI1 device, it has
to be only with a single UMP Group. Correct the attribute when a
device declares it wrongly.
Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing")
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240722140610.10845-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a device tries to update the FB name string even if its Endpoint
is declared as static, we should skip it, just already done for the FB
info update reply.
Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing")
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240722135929.8612-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When an inquiry of the current protocol via UMP Stream Configuration
message fails by some reason, we may leave the current protocol
undefined, which may lead to unexpected behavior. Better to assume a
valid protocol found in the protocol capability bits instead.
For a device that doesn't support the UMP v1.2 feature, it won't reach
to this code path, and USB MIDI GTB descriptor would be used for
determining the protocol, instead.
Link: https://lore.kernel.org/r/20240529164723.18309-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a UMP Stream Configuration message is received, the driver tries
to switch the protocol, but there was no sanity check of the protocol,
hence it can pass an invalid value. Add the check and bail out if a
wrong value is passed.
Fixes: a79807683781 ("ALSA: ump: Add helper to change MIDI protocol")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20240529164723.18309-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We can simplify the code gracefully with new guard() macro and co for
automatic cleanup of locks.
Only the code refactoring, and no functional changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240227085306.9764-2-tiwai@suse.de
|
|
snd_ump_legacy_open() didn't return the error code properly even if it
couldn't open. Fix it.
Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20240220150843.28630-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Filling the rawmidi name and substream name can be truncated, and this
leads to spurious compiler warnings due to -Wformat-truncation.
Although the truncation is the expected behavior, it'd be better to
truncate the string within "(...)"
This patch puts the precision specifies to each %s for fitting the
words within the size-limited strings.
Fixes: 5f11dd938fe7 ("ALSA: usb-audio: Attach legacy rawmidi after probing all UMP EPs")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308251844.1FuQYsql-lkp@intel.com/
Link: https://lore.kernel.org/r/20230826072151.23408-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When the UMP Endpoint is declared as "static", that is, no dynamic
reassignment of UMP Groups, it makes little sense to expose always all
16 groups with 16 substreams. Many of those substreams are disabled
groups, hence they are useless, but applications don't know it and try
to open / access all those substreams unnecessarily.
This patch limits the number of UMP legacy rawmidi substreams only to
the active groups. The behavior is changed only for the static
endpoint (i.e. devices without UMP v1.1 feature implemented or with
the static block flag is set).
Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support")
Link: https://lore.kernel.org/r/20230824075108.29958-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
To make it clearer which legacy substream corresponds to which UMP
group, fill the subname field of each substream object with the group
number and the endpoint name, e.g. "Group 1 (My Device)".
Ideally speaking, we should have some better link information to the
derived UMP, but it's another feature extension.
Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support")
Link: https://lore.kernel.org/r/20230824075108.29958-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The legacy rawmidi devices are the shadows of the main UMP devices,
hence it's better to initialize them after all UMP Endpoints are
parsed. Then, at the moment the legacy rawmidi is created, we already
know the static flag or the proper EP name string, and we can fill
those information at UMP core side instead of fiddling the attributes
at a later point.
Fixes: ec362b63c4b5 ("ALSA: usb-audio: Enable the legacy raw MIDI support")
Link: https://lore.kernel.org/r/20230824075108.29958-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch detaches the struct device from the snd_rawmidi object by
allocating via snd_device_alloc(), just like done for other devices.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Yet more preliminary work for the upcoming USB gadget support.
Now export the helpers to convert between legacy MIDI1 and UMP data
for handling the MIDI 1.0 USB interface. The header file is moved to
include/sound.
The API functions are slightly changed, so that they can be used
without the direct access to snd_ump object. The allocation is done
in ump.c itself as it's a simple kcalloc().
Link: https://lore.kernel.org/r/20230623075530.10976-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is another preliminary patch for USB MIDI 2.0 gadget driver.
Export the currently local snd_ump_receive_ump_val(). It can be used
by the gadget driver for processing the UMP data.
Link: https://lore.kernel.org/r/20230621110241.4751-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is another preliminary patch for USB MIDI 2.0 gadget driver.
Add a new flag, no_process_stream, to snd_ump for suppressing the UMP
Stream message handling in UMP core.
Link: https://lore.kernel.org/r/20230621110241.4751-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is a preliminary patch for MIDI 2.0 USB gadget driver.
Export a new helper to allow changing the current MIDI protocol from
the outside.
Link: https://lore.kernel.org/r/20230621110241.4751-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
UMP v1.1 spec allows to inform whether the function blocks are static
and not dynamically updated. Add a new flag bit to
snd_ump_endpoint_info to reflect that attribute, too.
The flag is set when a USB MIDI device is still in the old MIDI 2.0
without UMP 1.1 support. Then the driver falls back to GTBs, and they
are supposed to be static-only.
Link: https://lore.kernel.org/r/20230612081054.17200-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
UMP v1.1 supports the protocol switch via a UMP Stream message. When
it's received, we need to take care of the midi_version field in the
corresponding sequencer client, too.
This patch introduces a new ops to notify the protocol change to
snd_seq_ump_ops for handling it.
Link: https://lore.kernel.org/r/20230612081054.17200-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch implements the handling of the dynamic update of FB info.
When the FB info update is received after the initial parsing, it
means the dynamic FB info update. We compare the result, and if the
actual update is detected, it's notified via a new ops,
notify_fb_change, to the sequencer client, and the corresponding
sequencer ports are updated accordingly.
Link: https://lore.kernel.org/r/20230612081054.17200-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch adds the basic support for UMP Endpoint and UMP Function
Block parsing, which are extended in the new UMP v1.1 spec.
The patch provides a new helper function to perform the query of the
UMP Endpoint information and builds up the UMP blocks based on UMP
Function Block information. For the communication over the UMP
Endpoint, it opens the rawmidi device once internally, inquiries the
UMP Endpoint and Function Block info by sending new UMP Stream
messages, and waits for the response for each query.
The new UMP spec allows to update the FB info and change its
associated groups or its activeness on the fly, too. For catching it,
the UMP core keeps watching the incoming UMP messages, and
snd_ump_receive() handles the incoming UMP Stream messages to refresh
the FB info.
Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add a few more fields to snd_ump_endpoint_info and snd_ump_block_info
that are added in the new v1.1 spec. Those are filled by the UMP Stream
messages.
The rawmidi protocol version is bumped to 2.0.4 to indicate those
updates.
Also, update the proc outputs to show the newly introduced fields.
Link: https://lore.kernel.org/r/20230612081054.17200-2-tiwai@suse.de
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 extends the UMP core code to support the legacy MIDI 1.0
rawmidi devices. When the new kconfig CONFIG_SND_UMP_LEGACY_RAWMIDI
is set, the UMP core allows to attach an additional rawmidi device for
each UMP Endpoint. The rawmidi device contains 16 substreams where
each substream corresponds to a UMP Group belonging to the EP. The
device reads/writes the legacy MIDI 1.0 byte streams and translates
from/to UMP packets.
The legacy rawmidi devices are exclusive with the UMP rawmidi devices,
hence both of them can't be opened at the same time unless the UMP
rawmidi is opened in APPEND mode.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is a code refactoring for abstracting the rawmidi access to the
UMP's own helpers. It's a preliminary work for the later code
refactoring of the UMP layer.
Until now, we access to the rawmidi substream directly from the
driver via rawmidi access helpers, but after this change, the driver
is supposed to access via the newly introduced snd_ump_ops and
receive/transmit via snd_ump_receive() and snd_ump_transmit() helpers.
As of this commit, those are merely wrappers for the rawmidi
substream, and no much function change is seen here.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
UMP devices may have more interesting information than the traditional
rawmidi. Extend the rawmidi_global_ops to allow the optional proc
info output and show some more bits in the proc file for UMP.
Note that the "Groups" field shows the first and the last UMP Groups,
and both numbers are 1-based (i.e. the first group is 1).
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
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>
|
