[RFC] ALSA: how should a card name that is not ASCII be exposed?

[RFC] ALSA: how should a card name that is not ASCII be exposed?

[otzelot2021]

Hi,

before writing more code I would like to ask whether the problem below
is worth solving in the kernel at all, and if so, which of the possible
shapes you would prefer.

The problem
-----------

struct snd_card has three strings that exist only to be shown to a
human: shortname, longname and mixername.  They are fixed-size byte
arrays with no defined character encoding, so everything treats them as
ASCII.

That assumption does not hold on USB.  usb_string() converts the
UTF-16LE string descriptors of a device into UTF-8, so dev->product and
dev->manufacturer can already contain multi-byte characters today.
usb_audio_make_shortname() then does:

     strscpy(card->shortname, dev->product);

into a 32-byte array.  If the name is longer, strscpy() cuts it at a
byte boundary, which for a multi-byte character means the last sequence
in shortname is truncated.  What user space receives through
SNDRV_CTL_IOCTL_CARD_INFO is then not valid UTF-8, and it has no way to
repair it: the missing bytes are gone.  longname has the same issue with
its 80 bytes, and it is the string that ends up in /proc/asound/cards.

So this is not about adding a feature to a working field; the current
field can already produce a broken string, silently.

Who is affected
---------------

Users whose devices are named in their own language: a USB interface
sold in Japan, China, Korea or Russia, or a European product with an
umlaut or an accent in the vendor name.  32 bytes is 8 CJK characters,
and a vendor name plus a product name rarely fits in that.

What they see today is either a cut-off name or a name with a broken
character at the end, depending on the length.  Desktop stacks
(PipeWire, GNOME, KDE) show the string as-is, so the damage is visible
in the device picker.

I have not found an existing bug report for this, which I take as a
sign that it is a real but low-frequency annoyance rather than a fire.
That is part of what I am asking about.

The cheap option, which may well be the right one
-------------------------------------------------

Declare the existing fields UTF-8 and make the truncation stop cutting
inside a sequence.  No new fields, no new UAPI, one helper in the copy
path.  It fixes the "broken character" half of the problem immediately.

What it does not fix is the size: 32 bytes stays 8 CJK characters, so
the name is still cut, just cleanly.  And it retroactively gives an
encoding to a field that has been encoding-agnostic for 25 years, which
may or may not be acceptable to you.

If you think this is enough, I am happy to send just that.

The larger option
-----------------

Add UTF-8 successors of the three fields, kept alongside the ASCII ones
rather than replacing them, allocated on demand like card->components
now is.  Either side may be empty, so nothing may assume a name is
present and every reader keeps a fallback.  Drivers fill both and keep
them semantically in sync.

For user space this needs no new ioctl: SNDRV_CTL_IOCTL_CARD_BYTES
already carries a variable-length card string with a type discriminator
that was added for exactly this kind of extension, so three more type
values would do.  Nothing existing changes, and an old kernel returns
-EINVAL for an unknown type, which a reader can treat as "use the ASCII
field".

id, driver and components would deliberately keep no UTF-8 counterpart
for the time being. They are not display names: id is the unique handle 
and part of path
names, driver is what alsa-lib matches configuration against, and
components is a token list.

Questions
---------

1. Is this worth solving in the kernel, or should a desktop stack carry
    a name database and leave the kernel fields as they are?

2. If it is: cheap option, larger option, or both (the cheap one as a
    fix, the larger one as the long-term path)?

3. On limits.  For card->components you asked to drop the artificial
    size cap.  The same question applies here: a per-field byte limit
    (I used four times the ASCII field size, so the same number of
    characters always fits), or no limit at all with the ioctl reporting
    the length?

4. On validation.  The kernel cannot normalise to NFC without depending
    on CONFIG_UNICODE, and it cannot detect homoglyphs at all, so both
    stay recommendations.  It can cheaply reject malformed UTF-8, control
    characters, non-characters and the invisible/bidi formatting
    characters that are the spoofing vector one actually can catch.  Is
    that the right line, or should the kernel pass bytes through and
    leave all of it to user space?

5. Who would consume this?  A kernel-side field with no user is not
    worth your review time.  Should I take this to the alsa-lib and
    PipeWire people first and come back with their answer?

6. If the fields exist, does exposing them as read-only sysfs
    attributes on the card device make sense in addition to the ioctl
    (udev rules, inspecting a card before opening it), or is the ioctl
    alone the right surface?

Disclosure
----------

I have a working implementation of the larger option (core fields plus
validation, the CARD_BYTES types, KUnit coverage, usb-audio as the
first user, documentation).  I am deliberately not posting it yet
because the questions above decide its shape.  Say the word and I will
send it as an RFC series.

That implementation was written with the help of an LLM coding
assistant; per Documentation/process/coding-assistants.rst it will
carry an Assisted-by tag, and I will of course carry the
Signed-off-by and the responsibility for it.

Thanks,

Re: [RFC] ALSA: how should a card name that is not ASCII be exposed?

[Jaroslav Kysela]

On 9/14/26 18:46, otzelot2021@outlook.de wrote:

> The larger option
> -----------------
> 
> Add UTF-8 successors of the three fields, kept alongside the ASCII ones
> rather than replacing them, allocated on demand like card->components
> now is.  Either side may be empty, so nothing may assume a name is
> present and every reader keeps a fallback.  Drivers fill both and keep
> them semantically in sync.
> 
> For user space this needs no new ioctl: SNDRV_CTL_IOCTL_CARD_BYTES
> already carries a variable-length card string with a type discriminator
> that was added for exactly this kind of extension, so three more type
> values would do.  Nothing existing changes, and an old kernel returns
> -EINVAL for an unknown type, which a reader can treat as "use the ASCII
> field".
> 
> id, driver and components would deliberately keep no UTF-8 counterpart
> for the time being. They are not display names: id is the unique handle
> and part of path
> names, driver is what alsa-lib matches configuration against, and
> components is a token list.

This looks like a best extension proposal IMHO. The current apps don't have 
any assumptions that the fields are in other character coding than ASCII.

				Jaroslav

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

Re: [RFC] ALSA: how should a card name that is not ASCII be exposed?

[Takashi Iwai]

On Mon, 14 Sep 2026 18:59:53 +0200,
Jaroslav Kysela wrote:
> 
> On 9/14/26 18:46, otzelot2021@outlook.de wrote:
> 
> > The larger option
> > -----------------
> > 
> > Add UTF-8 successors of the three fields, kept alongside the ASCII ones
> > rather than replacing them, allocated on demand like card->components
> > now is.  Either side may be empty, so nothing may assume a name is
> > present and every reader keeps a fallback.  Drivers fill both and keep
> > them semantically in sync.
> > 
> > For user space this needs no new ioctl: SNDRV_CTL_IOCTL_CARD_BYTES
> > already carries a variable-length card string with a type discriminator
> > that was added for exactly this kind of extension, so three more type
> > values would do.  Nothing existing changes, and an old kernel returns
> > -EINVAL for an unknown type, which a reader can treat as "use the ASCII
> > field".
> > 
> > id, driver and components would deliberately keep no UTF-8 counterpart
> > for the time being. They are not display names: id is the unique handle
> > and part of path
> > names, driver is what alsa-lib matches configuration against, and
> > components is a token list.
> 
> This looks like a best extension proposal IMHO. The current apps don't
> have any assumptions that the fields are in other character coding
> than ASCII.

I personally find it OK to have UTF-8 strings in short / long / mixer
names.  That's no new problem, and it's been over decades.  Of course,
a broken letter at the end could be a problem and we can fix it in
either kernel or alsa-lib, too.

OTOH, I'm fine with the extension, too.  That doesn't sound too
intrusive.

But, an open question is what should we fill into the short/long/mixer
names in ASCII, instead of vendor / product names?  With embedded IDs
like "USB 1234:abcd"?  Or shall we still pass the vendor / product
names if they are ASCII only, and falling back only if they are
non-ASCII?


thanks,

Takashi

Re: [RFC] ALSA: how should a card name that is not ASCII be exposed?

[Jaroslav Kysela]

On 9/15/26 12:53, Takashi Iwai wrote:
> On Mon, 14 Sep 2026 18:59:53 +0200,
> Jaroslav Kysela wrote:
>>
>> On 9/14/26 18:46, otzelot2021@outlook.de wrote:
>>
>>> The larger option
>>> -----------------
>>>
>>> Add UTF-8 successors of the three fields, kept alongside the ASCII ones
>>> rather than replacing them, allocated on demand like card->components
>>> now is.  Either side may be empty, so nothing may assume a name is
>>> present and every reader keeps a fallback.  Drivers fill both and keep
>>> them semantically in sync.
>>>
>>> For user space this needs no new ioctl: SNDRV_CTL_IOCTL_CARD_BYTES
>>> already carries a variable-length card string with a type discriminator
>>> that was added for exactly this kind of extension, so three more type
>>> values would do.  Nothing existing changes, and an old kernel returns
>>> -EINVAL for an unknown type, which a reader can treat as "use the ASCII
>>> field".
>>>
>>> id, driver and components would deliberately keep no UTF-8 counterpart
>>> for the time being. They are not display names: id is the unique handle
>>> and part of path
>>> names, driver is what alsa-lib matches configuration against, and
>>> components is a token list.
>>
>> This looks like a best extension proposal IMHO. The current apps don't
>> have any assumptions that the fields are in other character coding
>> than ASCII.
> 
> I personally find it OK to have UTF-8 strings in short / long / mixer
> names.  That's no new problem, and it's been over decades.  Of course,
> a broken letter at the end could be a problem and we can fix it in
> either kernel or alsa-lib, too.

The fields are printed in procfs, so the kernel code should do this.

> OTOH, I'm fine with the extension, too.  That doesn't sound too
> intrusive.

Accepting UTF-8 in fields and provide short-long/long-long name through 
SNDRV_CTL_IOCTL_CARD_BYTES when it does not fit to the standard field length 
is also acceptable (as for the components string). But the driver name and ID 
fields should be normalized somehow to not add another layer of complexity.

 > With embedded IDs like "USB 1234:abcd"?

Yes, it may be an acceptable solution. Note that it's a problem probably for 
the ID field only, because USB driver uses driver and mixer fields hardcoded as:

   driver_name: USB-Audio
   mixer_name: USB Mixer

					Jaroslav

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