06:03 <albsen[m]> morning, just an update for my x13s: I figured out that I was on debian testing (trixie). now I set it up so that I can pull in "sid/unstable" packages and upgrade to 6.6.9 so far no issues on 6.6.9; today I'll try to build 6.7 mainline and set it up. on 6.6.9 I removed all the iommu params but kept aspm as recommended here: https://github.com/jhovold/linux/wiki/X13s

06:07 <steev> are you including the config change that ema pointed to a few days back

06:46 <albsen[m]> <steev> "are you including the config..." <- no, let me check what he said in the log

07:05 <albsen[m]> <steev> "are you including the config..." <- I setup the firmware and linked it as suggested here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057040 I also made a custom hook to include the correct firmware files in initramfs (similar to this one https://drive.google.com/file/d/1cOktGsw4TMQ1_Z-6Z-NbINQnYPJPuOOH/view) and it looks like they're being loaded I can see that when booting; I've already started looking at the config

07:05 <albsen[m]> change ema is proposing in this changeset: https://salsa.debian.org/kernel-team/linux/-/merge_requests/995/diffs?commit_id=0708910e2e64da1a806f23ac993c144361478cbd to build 6.7 with (but haven't done that) once I'm on 6.7 I'll see why audio is still dodgy but thats likely due to the alsa-ucm-conf from sid not yet installed and configured.

07:06 <steev> alsa-ucm-conf does not have a release with the patches yet, afaik

07:07 <albsen[m]> steev: where do I get the patches from?

07:07 <steev> https://github.com/alsa-project/alsa-ucm-conf

07:08 <albsen[m]> i think they moved to gitlab, this one looks old

07:09 <steev> wut?

07:09 <steev> it's literally 2 days ago for latest commit?

07:09 <albsen[m]> 5 years ago, last change

07:09 <albsen[m]> hm

07:09 <steev> https://github.com/alsa-project/alsa-ucm-conf/commits/master/

07:09 <steev> literally 2 days ago

07:10 <albsen[m]> sry, I only looked at the folders o0

07:10 <albsen[m]> nvrmind :/

07:10 <steev> though it also looks like jhovold got some commits in recently as well

07:10 <steev> that should fix some of the quietness maybe?

07:13 <steev> clover[m]:

07:13 <steev> clover[m]: https://github.com/alsa-project/alsa-ucm-conf/pull/382 silly me, hit enter too soon

07:40 <steev> maybe i'll update my fork and submit a merge request

07:40 <steev> https://salsa.debian.org/steev/alsa-ucm-conf (it's out of date, so don't use debian users)

07:46 <craftyguy> maybe we'll get an alsa-ucm release soon :P

07:48 <steev> twould be nice

08:10 <jhovold> steev: please don't try the fixed ucm files wihout this series in place to limit the speaker gain:

08:11 <jhovold> https://lore.kernel.org/all/20240118165811.13672-1-johan+linaro@kernel.org/

08:11 <jhovold> I'm still sorting out some details and was gonna announce it here when it's ready

08:12 <jhovold> But yes, hardware volume control is currently broken, but with that fixed you should watch out so you don't toast your speakers at the highest gain setting

08:12 <jhovold> I'm limiting it in the machine driver for now

08:12 <jhovold> I'll post some more details later today.

08:19 <Jasper[m]> <steev> "clover: https://github.com/alsa..."; <- Ooohh

08:20 <Jasper[m]> <jhovold> "steev: please don't try the..." <- Oh

08:20 <Jasper[m]> I kinda hope that fix gets merged before the alsa-ucm-conf changes

08:20 <Jasper[m]> Would not be fun to accidentally fry the speakers

08:21 <steev> jhovold: oh, good to know, i wasn't planning to test it just yet, but was pointing it out, good to know - the good news is... they don't seem to release alsa-ucm-conf very often ;)

08:21 <Jasper[m]> Does this also fix the gain on the jaco?

08:21 <jhovold> too late for that, but hopefully before the release

08:21 <Jasper[m]> s/jaco/jack/

08:21 <jhovold> Jasper[m]: correct, I started looking at that issue and went down a alsa rabit hole

08:22 <jhovold> turns out everone has been using software volume control so far due to a bug in the UCM files

08:22 <Jasper[m]> jhovold: Yes, sorry, that's what I meant

08:22 <jhovold> so the line out level has definitely been too high for line-level as you reported

08:22 <jhovold> same thing with the speakers

08:22 <craftyguy> would this do anything to help pops and such?

08:22 <jhovold> everyone has been using the lowest amplification, unless you changes the mixer control manually

08:23 <Jasper[m]> jhovold: Awesome, thank you for checking it out

08:23 <jhovold> nothing so far has prevented you from drivng the speakers at max power if you did so through alsamixer

08:23 <steev> modern audio :)

08:23 <jhovold> i want to limit that in the machine driver for everyone, until srinik has been able to run some more tests at higher gains to determine which levels are safe

08:24 <jhovold> craftyguy: there are still some pops on suspend/reboot and such, so not directly related

08:25 <craftyguy> how do they determine which levels are safe? just curious

08:25 <Jasper[m]> jhovold: Sounds like something for speakersafetyd no?

08:25 <jhovold> someone needs to be willing to sacrifice their speakers and send square waves at different gain settings

08:26 <steev> sounds like a job for not me

08:26 <jhovold> i don't recommend anyone to try that at home (excpect srinik) ;)

08:26 <Jasper[m]> Ah yes, the company provided test device

08:26 <Jasper[m]> :D

08:26 <jhovold> Jasper[m]: Qualcomm has a speaker protection feature that can be enabled in the DSP so we won't be using speakerprotd

08:27 <Jasper[m]> jhovold: I may be conflating the name of Marcan's testing method with the name for the daemon

08:27 <jhovold> it's probably going to take quite a while before we can enable that feature, so we need some limits in place until then

08:27 <steev> nah, you have the right name Jasper[m]

08:27 <jhovold> Jasper[m]: ah, yeah

08:28 <jhovold> steev: speakerprotd is the asahi user-space implementation for speaker protection, I think they test their speeakers manually

08:29 <steev> i thought they named it speakersafetyd

08:29 <steev> or maybe that's just the repo name

08:29 <jhovold> maybe that was it

08:29 <jhovold> i don't really know

08:29 <steev> git@github.com:asahilinux/speakersafetyd.git

08:30 <steev> dunno which the dameon is, but i glanced it over when i saw them talking about it

08:30 <steev> though it looks like they lock it down to only mac devices using snd-soc-macaudio

08:30 <steev> via udev rule

08:32 <steev> i do wish there was an easier way to track patch sets

08:32 <steev> since it looks like you'll have a v4

08:33 <jhovold> don't worry, i'll include in my wip branches shortly

08:33 <steev> i'm in no rush, i figure rc1 will have the goodies :D

08:34 <steev> if those changes need the patches, i need them to be in -next before debian will consider them for inclusion in kernels anyway

08:35 <jhovold> i've tagged the asoc fixes adding the limits for stable, so they should be backported soon enough too

09:49 <_[m]1> waw it's never easy huh 😲 thanks for all the work 🙂

11:57 <Jasper[m]> <steev> "though it looks like they lock..." <- Well yeah, I think they want people to port it to their devices first

11:58 <Jasper[m]> In a world where hardware control of the amp in the x13s was already present in the driver, you wouldn't need speakersafetyd

11:59 <Jasper[m]> The Macs don't have a possibility for that from what I've read. It's purely in software

11:59 <Jasper[m]> <steev> "if those changes need the..." <- I think it's the same for Fedora

16:22 <clover[m]> steev: it definitely fixes the quietness

16:23 <jhovold> clover[m]: i hope you applied my limiting patches?

16:23 <jhovold> otherwise it sure it loud, and I would not recommend using it for long periods

16:26 <jhovold> the ucm and volume fixes gives a louder sound generally too, but I recommend using the limiting patches

16:26 <jhovold> for now

16:28 <clover[m]> looks like there is 5 patches? any way i can get them in one big patch file?

16:44 <jhovold> Here's an updated wip branch for the X13s:

16:44 <jhovold> - https://github.com/jhovold/linux/commits/wip/sc8280xp-v6.7

16:44 <jhovold> Changes include

16:44 <jhovold> - fix speaker PA volume control

16:44 <jhovold> - add speaker playback volume limits (needed with new UCM files)

16:45 <jhovold> - fix digital gain bug that can result in distorted (or too quiet) speaker playback

16:45 <jhovold> There was a bug in the UCM files that prevented hardware volume control and, for example, resulted in over-driven line-out (jack) and lower speaker volume than intended. This is fixed here:

16:45 <jhovold> - https://github.com/alsa-project/alsa-ucm-conf/pull/382

16:45 <jhovold> WARNING: Make sure you apply the kernel fixes before switching.

16:46 <jhovold> clover[m]: you can use my lasest wip branch, or I'm sure steev will pick the fixes up soonish

16:49 <clover[m]> i grabbed the raw version of each patch and catted them together. seems like it worked... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/YYYglcsVHZPikeFYsfDgZVZE>)

16:51 <clover[m]> maybe i should just roll back alsa and wait

16:52 <clover[m]> it is a work day after all :)

16:54 <jhovold> may be wise, i've been accidentally pushing my speakers (and ears) a bit more than intended a few times these past couple of weeks

16:55 <jhovold> at least we know that the laptop

16:55 <jhovold> *can* get really loud now...

16:56 <clover[m]> yeah, its pretty awesome :)

17:08 <Jasper[m]> <jhovold> " - https://github.com/jhovold/..."; <- Thanks! Can't wait for it to land upstream

17:16 <steev> yep, i'll be picking them up shortly :D was in work meetings

17:17 <jhovold> steev: I sent a v4 of the asoc fixes today that I included in my wip branch

17:18 <jhovold> https://lore.kernel.org/lkml/20240119112420.7446-1-johan+linaro@kernel.org/

17:19 <steev> jhovold: your wip branch only has 3 of the 4?

17:19 <jhovold> right, the last one is just a cleanup

17:20 <steev> ah okay

17:21 <jhovold> I'll include them all in my coming rc1 branch, but i just cherry picked the three for the 6.7 branch

17:21 <steev> works for me :)

17:59 <steev> exciting to have audio i can hear

20:20 <steev> clover[m]: pushed updated 6.7 branch, also includes some venus clk changes that increase the delay for venus clock resets, a couple minor fixes, v1 of bamse's gpu thermal sensor addition, and of course, the v4 of the audio fixes johan mentioned above

20:43 <_[m]1> it's this one right lenovo-x13s-linux-6.7.y

20:55 <steev> si

20:58 <_[m]1> damn it builds fast

21:02 <jglathe> Update on ath11k sleep issue: Volterra and X13s now running on 6.7 for a week now, Volterra non-stop with (whatever) sleep - no issues with this.

21:02 <jglathe> removed the aspm kernel parameter from the cmdline

21:06 <jglathe> on the X13s these are left: pd_ignore_unused clk_ignore_unused efi=noruntime

21:20 <_[m]1> seems my vpn doesn't reconnect after sleep mm

21:25 <claydoh[m]> For the Flex 5G, are there any preferred/up-to-date docs regarding a basic OS install, or is the github page still the go-to?

23:41 <clover[m]> Linux 6.7 and latest alsa-ucm-conf pushed to arch repo