Dne 08. 06. 20 v 11:22 Takashi Iwai napsal(a):
On Mon, 08 Jun 2020 11:01:43 +0200, Jaroslav Kysela wrote:
Dne 08. 06. 20 v 10:44 Takashi Iwai napsal(a):
On Mon, 08 Jun 2020 10:37:12 +0200, Jaroslav Kysela wrote:
Dne 08. 06. 20 v 9:15 Takashi Iwai napsal(a):
Replace the open-code with the new QUIRK_DEVICE_PROFILE() macro for simplicity.
Fixes: 0c5086f56999 ("ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock") Signed-off-by: Takashi Iwai tiwai@suse.de
Takashi, could we export the profile (hint) for new USB cards via the components string - snd_component_add()? The long name seems not appropriate for this. It's a GUI string (which is mangled now).
It's possible, and maybe we should move to it, but we'd need to provide in card->longname for now because the component support in user-space side isn't in major releases yet. The longname is ugly, but that's the only way that works stably right now.
Also, we need a common helper function for adding the component string in the kernel side, too, not specific to USB-audio.
There is already snd_component_add() function, so we need to settle only the identification prefix for those "model" strings.
It would be nice to duplicate this info for the moment (the components string should be shorter than used for long name).
Yes, what we need a concrete definition. The implementation in kernel-side must be easy :)
Perhaps, we can just add "hw:<hint>" component string for the more finer hardware identification, like:
$ amixer -c 0 info Components : 'USB0bda:58fe hw:VideoMic'
I don't mind what form, but would the example above work as a UCM profile properly?
It should work for UCM2. UCM2 can compare the components string and load or use the appropriate piece of configuration. So it means that ucm2/USB-Audio/USB-Audio.conf will handle this.
I also added the possibility to extract 'VideoMic' (regex) from the 'hw:VideoMic' string and include the file from the custom path (syntax 3 in UCM2). So we can end with the ucm2/USB-Audio/HiFi-VideoMic.conf file.
So basically, the prefix may be driver specific but consistent, so we can do a match against it in the user space. Or we may use 'hint:<hwid>' or so.
Jaroslav
thanks,
Takashi