On 12/11/2017 07:40 AM, Takashi Iwai wrote: > On Mon, 11 Dec 2017 13:30:35 +0100, > Hans de Goede wrote: >> Hi All, >> >> This weekend I've created a modified ucm config based on: >> >> https://github.com/plbossart/UCM/tree/master/chtrt5645 >> >> For a board which has a single speaker connected to the >> left channel (standard mono speaker setup) and a stereo >> headphone jack with working jack detection. >> >> I've been unable to come up with a ucm file which allows >> selecting between a "Stereo Speaker + Headphone" vs >> "Mono Speaker + Headphone" output profile. >> >> https://github.com/plbossart/UCM/tree/master/byt-rt5640 >> has "Mono Speaker", "Stereo Speaker" and "Headphone" >> profiles but does not auto-switch between Headphone >> and speaker based on jack detection, I've been unable to >> allow selecting either stereo or mono speaker while >> keeping auto-switching to/from the headphones. >> >> But thinking more about this I don't think that having >> "Stereo Speaker + Headphone" and "Mono Speaker + Headphone" >> profiles is the answer. Profiles make sense on machines with >> a bunch of outputs where we don't no what the user is going >> to plug in, but in this case the stereo vs mono speaker >> distinction is a clear property of the device, which we >> should IMHO autodetect based on the device-model. >> >> So I think we need a way to have different ucm files per board, >> so instead of loading /usr/share/ucm/chtrt5645/*.conf on my >> device, alsa should try to load /usr/share/ucm/chtrt5645-<boardname>/*.conf >> >> Specifically I'm thinking about using udev + hwdb (dmi string) >> matching to set an ALSA_UCM_NAME udev property. >> >> If the consensus is that this is a good idea I can take a shot >> at writing patches for this (in my spare time mostly), the >> downside of this approach is it would cause a dependency on >> libudev for the alsa ucm code. > You don't need to patch, I guess. The recent code should set a string > generated from DMI as the longname of the card, and alsa-lib UCM > parser prefers the longname to the driver name field. That is, > /usr/share/ucm/$LONGNAME/$LONGNAME.conf would be read at first, then > /usr/share/ucm/$DRIVER/$DRIVER.conf is used as fallback. > The long name is really awful at times, I've seen PulseAudio try to load UCM profiles of boards with over 40 characters with multiple repeats. Also from a maintainability perspective we need the include mechanism and I don't think it was ever merged - or what I saw wasn't very useful.
