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

[Takashi Iwai <tiwai@suse.de>]

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