[PATCH] ALSA: core: sysfs: show components string

[Takashi Sakamoto]

On Mon, Mar 23, 2020 at 10:34:23PM -0500, Pierre-Louis Bossart wrote:
> On 3/23/20 8:53 PM, Takashi Sakamoto wrote:
> > Hi,
> > 
> > On Mon, Mar 23, 2020 at 02:36:23PM -0500, Pierre-Louis Bossart wrote:
> > > Add attribute and show the components string. This is useful to see
> > > what is provided to userspace and e.g. used by UCM to understand the
> > > card configuration:
> > > 
> > > root at plb:~# more /sys/class/sound/card0/components
> > > HDA:8086280b,80860101,00100000 cfg-spk:2 hs:rt711 spk:rt1308 mic:rt715
> > > 
> > > Note that the style uses what's recommended by checkpatch.pl and is
> > > slightly different from other sysfs attributes.
> > > 
> > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
> > > ---
> > >   sound/core/init.c | 12 ++++++++++++
> > >   1 file changed, 12 insertions(+)
> > I have a concern about this patch in a point of userspace interface.
> > 
> > The 'component' field of 'struct snd_ctl_card_info' is just defined to
> > have strings with space-separated chunks, and its actual value is not
> > so fine-documented, thus it's largely different depending of developers
> > of each driver.
> 
> In case you missed it, the components are used by machine drivers to report
> e.g. number of speakers, mics, etc, so that UCM can find the right
> configuration. For a given family of products, the syntax will be fixed,
> e.g. hs stands for headset codec, etc.
 
Actually the syntax is just fixed to devices which a part of ALSA
in-kernel driver supports. There's no specification widely used to all of
ALSA in-kernel drivers.

(Of cource, it covers many of actual devices which assumed users own.)

> > $ cat include/uapi/sound/asound.h
> >       ...
> >   941 struct snd_ctl_card_info {
> >           ...
> >   950     unsigned char components[128];  /* card components / fine identification, delimited with one space (AC97 etc..) */
> >   951 };
> > 
> > On the other hand, the node of sysfs is quite common in Linux because
> > it's tightly coupled to kernel objects. Let you see files under
> > 'Documentation/ABI/'. We can find efforts to maintain sysfs node so
> > safe and stable. Due to this reason, it's better to take more care when
> > adding new node.
> > 
> > Would I request you the reason to add this node and the reason that
> > current ALSA control interface doesn't satisfy your requirement?
> 
> simplicity for user support. Anyone can peak at a sysfs file, not everyone
> is familiar with the alsa control interface.
> 
> We get lots of bug reports from people who are asking for configuration
> help, and the simpler the command is the better.

For my information, would I request you to disclose the part of such reports?

I need supplemental information about the reason to add the alternative
path to expose it, especially the reason that no developers work to
improve existent tool relevant to UCM and are going to wish to add the
alternative without utilizing ALSA control character device.


Regards

Takashi Sakamoto