[alsa-devel] Per board ucm files on x86?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 11-12-17 14:40, 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.

I'm afraid this does not work entirely as one would expect, after
opening /usr/share/ucm/$LONGNAME/$LONGNAME.conf which contains:

SectionUseCase."HiFi" {
         File "HiFi.conf"
         Comment "Default"
}

strace shows that alsa-lib opens:
/usr/share/ucm/$DRIVER/HiFi.conf and to get it to load the HiFi.conf
under /usr/share/ucm/$LONGNAME I need to do:

SectionUseCase."HiFi" {
         File "../gpd-win-pocket-rt5645/HiFi.conf"
         Comment "Default"
}

Leading to the following in strace:

openat(AT_FDCWD, "/usr/share/alsa/ucm/chtrt5645/../gpd-win-pocket-rt5645/HiFi.conF", O_RDONLY) = 23

Which to me seems undesirable behavior by alsa-lib.

Regards,

Hans


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux