Dne 27. 09. 19 v 16:00 Jaska Uimonen napsal(a): > On Fri, 2019-09-27 at 12:57 +0200, Jaroslav Kysela wrote: >> Dne 27. 09. 19 v 12:07 Jaska Uimonen napsal(a): >>> On Tue, 2019-09-24 at 13:53 +0200, Jaroslav Kysela wrote: >>>> Dne 19. 09. 19 v 17:15 Pierre-Louis Bossart napsal(a): >>>>> On 9/19/19 9:54 AM, Mark Pearson wrote: >>>>>>> >>>>>>> Indeed UCM is required for all cases where SOF and >>>>>>> PulseAudio >>>>>>> are used. >>>>>>> >>>>>>> Our thinking was however to add this UCM file to the new >>>>>>> repository outside >>>>>>> of alsa-lib [1]. There is an on-going thread started by >>>>>>> Jaroslav to move those >>>>>>> files and relicense them as BSD-3-Clause [2] >>>>>>> >>>>>>> [1] >>>>>>> https://mailman.alsa-project.org/pipermail/alsa-devel/2019- >>>>>>> July/153257.html >>>>>>> [2] >>>>>>> https://mailman.alsa-project.org/pipermail/alsa-devel/2019- >>>>>>> September/155246.html >>>>>> >>>>>> Thanks Pierre. >>>>>> >>>>>> Do we have any approximate timelines on when and how this >>>>>> will >>>>>> happen? (I'm new to this) >>>>>> >>>>>> One of my main aims is that we have a customer using Debian >>>>>> and >>>>>> one of our platforms that require this change - I need to >>>>>> make >>>>>> sure I understand how this would roll out and what actions >>>>>> they >>>>>> need to take in the meantime if it's not going to be >>>>>> available in >>>>>> Debian. >>>>> >>>>> I think the first order would be to have the file cleaned-up, >>>>> with >>>>> its >>>>> Intel origin clearly stated with a signed-off-by tag. >>>>> >>>>> Then once this is done, the Debian package creation needs to be >>>>> handled >>>>> (using either the ALSA repo or the cloned version on SOF >>>>> GitHub). >>>>> I >>>>> don't have any experience with Debian packages so can't really >>>>> comment >>>>> on the effort it would take. >>>> >>>> I did some cleanups here: >>>> >>>> https://github.com/alsa-project/alsa-ucm-conf/commit/f796f0852a09 >>>> 7e23 >>>> 8fa9f5efb174e95b5ee6c8b7 >>>> >>>> Pierre, could you confirm the original source and are you ok with >>>> that? >>> >>> Cleanup looks fine to me, we should add still UCM "PlaybackVolume" >>> and >>> "CaptureVolume" settings, because otherwise Pulseaudio will use SW >>> volume only. This will make for example HDA led quirks useless... >>> (and actually CaptureVolume and PlaybackVolume in pulseaudio ucm >>> support is still not integrated, hopefully soon). Defining Capture >>> and >>> PlaybackVolume should not do any harm currently for user space. >>> >>> I can do that, Jaroslav you want PR against github or patches here >>> to mailing list? >> >> As you wish. Both ways are acceptable for me. Note that I did another >> cleanup >> for 'Bass Speaker' for Carbon X1 7th and merged 'import' branch to >> 'master' >> branch on github (so do the PR against master, if you like). >> >> Thanks, >> Jaroslav >> > > I made now: > https://github.com/alsa-project/alsa-ucm-conf/pull/1 > and > https://github.com/alsa-project/alsa-ucm-conf/pull/2 Thanks. Why switches (PlaybackSwitch/CaptureSwitch) are not defined, too? > It would be good if Lenovo and Canonical folks also check these. > > I'm testing this in Dell device with Ubuntu and twiddling outputs > and volumes/mutes from UI. PR 2 is assuming Pulseaudio HW control, > so not sure if the changes bad without it. BTW: Could you, Intel guys, review other UCM profiles for the SST drivers, too? It seems that PlaybackVolume is only in few other profiles and no one is using switches and capture CTL ID definitions. It basically means, that all UCM profiles are broken and only software volume is used in PA :-( Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
