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@xxxxxxx>
---
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
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
