From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info Date: Fri, 16 May 2014 07:42:26 +0200 Message-ID: References: <536F2BB8.8060002@ladisch.de> <5371E4D8.3030406@ladisch.de> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 7E68B264F03 for ; Fri, 16 May 2014 07:42:27 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Adam Goode Cc: alsa-devel@alsa-project.org, Clemens Ladisch List-Id: alsa-devel@alsa-project.org At Thu, 15 May 2014 16:47:03 -0700, Adam Goode wrote: > > On Tue, May 13, 2014 at 8:00 AM, Takashi Iwai wrote: > > > > At Tue, 13 May 2014 11:24:40 +0200, > > Clemens Ladisch wrote: > > > > > > Adam Goode wrote: > > > > On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch 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.) > > > > This sounds good to me. It's small enough and least impact to the > > existing API. > > > > I'm not opposing to creating /sys entries, though. But, if we do > > exposing to /sys, this has to be done properly. Namely, the question > > isn't only about the sequencer stuff but about all entries in /proc. > > So, this won't be a quick task, in anyway. > > > > > > Thanks for spending time on this. I like this proposal very much. I > plan to look at sending some patches in the next week or so for > review. > > One question I have for step 2 above: snd_ctl_card_info is full. I > don't see a way of adding to it without introducing a new ioctl > (SNDRV_CTL_IOCTL_CARD_INFO2 + struct snd_ctl_card_info2?) > > I am happy to do this, just wanted to make sure it was the right way. > (alsa-lib should hide this change through its accessors I believe.) Some extra IDs have been already added in card.component field. It's a string list separated by space letters, and USB-audio adds vendor and product hex numbers like USB12ab:ab12. Then user-space app can fetch more details by itself. Takashi