Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Adam Goode <agoode@chromium.org>
Cc: alsa-devel@alsa-project.org
Subject: Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info
Date: Tue, 13 May 2014 11:24:40 +0200	[thread overview]
Message-ID: <5371E4D8.3030406@ladisch.de> (raw)
In-Reply-To: <CAOf41Nka_a8Y08MwERBKrZdKCUFo5-NhxR0ULHtUye4aUaOKXg@mail.gmail.com>

Adam Goode wrote:
> On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > Adam Goode wrote:
> > > I am working on a seq implementation for Chrome, to replace the rawmidi
> > > implementation. I can retain the manufacturer extraction hack on the card,
> > > but seq requires yet another hack to guess the card for a particular seq
> > > client.
> > >
> > > A completely different solution would be to add all this info to sysfs
>
> > USB devices already have this information in sysfs.
>
> This is true. Unfortunately, here are the current steps to get this
> information:
> 1. Given a seq client, attempt to guess the card by making assumptions
>    about client->card numbering.
> 2. From the card, attempt to guess the manufacturer by making
>    assumptions about how longname is constructed. Or, attempt to
>    extract the usb information from the card info struct and then try
>    to get the info from /sys (but this gives us only the manufacturer
>    string from usb, not the quirk vendor name that the usb midi driver
>    knows about).
>
> What I would like to do is make these mappings explicit. Because Alsa
> is very ioctl driven, I was thinking the way to do this is through the
> existing ioctl API. But since I really just want to expose a lot more
> read-only info about the system, perhaps files in /sys would be an
> acceptable way to expose this information.

The ioctl API (and the library API on top of it) already exists.  Why
do you want to introduce another kind of API that cannot be used for
virtual devices?

> At least, I would like to take the rather detailed information stored
> in /prod/asound and expose this in a more sysfs way via /sys, then add
> more fields and info. Does this sound reasonable?

Almost all the information in /proc/asound is already available through
some ioctl, and the missing information can be added easily.


OK, here is my proposal:

1. Add the card number to snd_seq_client_info.  (For kernel drivers;
   user clients might have the PID here while we're at it.)

   (As long as you are interested only in USB devices, this might be all
   you need.)

2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
   this is almost always known, but most other drivers do not know the
   name of the card manufacturer (as opposed to the chip manufacturer).
   In those cases, the most informative name that a driver could provide
   would be based on a registered ID like "USB:0x1234", "PCI:0x5678", or
   "IEEE:0x9abcde".  (It's possible to look these up in usb.ids, pci.ids,
   and oui.txt, but I'm not sure if it would be a good idea to let
   alsa-lib do this lookup.)


Regards,
Clemens

  reply	other threads:[~2014-05-13  9:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-11  1:18 Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info Adam Goode
2014-05-11  7:50 ` Clemens Ladisch
2014-05-12 19:29   ` Adam Goode
2014-05-13  9:24     ` Clemens Ladisch [this message]
2014-05-13 15:00       ` Takashi Iwai
2014-05-15 23:47         ` Adam Goode
2014-05-16  5:42           ` Takashi Iwai
2014-05-16  7:26           ` Clemens Ladisch
2014-05-21  3:23             ` Adam Goode

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5371E4D8.3030406@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=agoode@chromium.org \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox