02:21 <akaWolf> I remember building of tdlib, ldd stage

03:00 <matalama> is there any initramfs modules depends for running external display on sc8280xp?

03:07 <robclark> not directly but maybe adsp remoteproc.. you can check that if `echo start > /sys/class/remoteproc/remoteproc0/state` fixes things

03:07 <robclark> (as root)

15:19 <clover[m]> sound levels are super low on x13s still, anything we can do about it?

15:25 <Jasper[m]> Implement the speaker protection functionality in the amp driver

15:25 <Jasper[m]> And then crank it

15:26 <travmurav[m]> <del>or get a fire extinguisher and just crank it</del>

15:27 <clover[m]> lol!

15:35 <vadikas[m]> asahi has a fancy daemon for that protection functionality written in rust.

15:36 <Jasper[m]> Yes, but that's software

15:37 <abby> so is the driver

15:42 <broonie> Speaker protection is more a userspace thing, the driver component of it is basically just recording a stream of measurements to userspace.

15:42 <broonie> The daemon that they've got is not specific to them and does roughly what anyone should do, I did suggest that they should name it something more general and try talking to ChromeOS and people but I'm not sure if anything happened there.

15:43 <Jasper[m]> <abby> "so is the driver" <- I'm (poorly) hinting to the fact that the amp itself has this functionality in hardware

15:43 <Jasper[m]> jhovold has mentioned before it's not working currently (because there's no driver)

15:43 <Jasper[m]> *driver implementation

15:44 <broonie> Does the amp actually implement the protection itself (usually with an onboard DSP) or does it stream sense data back to the host for feeding into a speaker protection algorithm?

15:45 <Jasper[m]> Haven't seen any info about that (yet), but the talk here has been that it implements it itself

15:45 <Jasper[m]> At least that's what I inferred

15:47 <broonie> I'd be a bit careful about assuming that given what hardware typically looks like and the tradeoffs with putting digital stuff in analog devices - it is possible but usually when vendors do this they ship some driver/userspace component on the host that plays a critical role.

15:48 <Jasper[m]> broonie: If I were working on it, I'd do more research where possible :p

15:49 <Jasper[m]> But iirc there were some issues with getting datasheets for the thing

15:50 <broonie> Yes, there's typically poor/no documentation and the algorithms are proprietary.

17:11 <flokli> that didn't stop asahi folks from implementing it ;-)

17:14 <flokli> https://github.com/AsahiLinux/speakersafetyd has some nice documentation on their approach, all the hardware-specific parameters are config files, it should be possible to add support for other speakers and other hardware too, assuming they work similarly.

17:34 <steev> broonie: iirc johan said it's in the DSP

17:34 <steev> i believe it's mentioned in the wrapping up arm laptop project talk he gave at linaro connect

17:34 <broonie> steev: The CODEC DSP or the AudioReach one?

17:34 <steev> that part, i do not nknow

17:35 <steev> admittedly, i don't know the difference between the two :)

17:37 <broonie> Well, just that if it's in the CODEC that'd be surprising but if it's in the DSP in the SoC that's the more normal design, it's just that instead of using a userspace daemon they use something running in the SoC DSP.

17:38 <broonie> So the CODEC would look very standard.

17:38 <Segfault[m]> i know qcom help customise the remoteproc firmware per-device and they really like offloading stuff like that to their dsps, it'd make sense that speaker protection was done in the dsp

17:38 <broonie> Yeah, it's not super surprising given that they have a DSP.

17:39 <broonie> Equally there shouldn't be any issue doing it in userspace if the DSP is hard to work with for some reason so long as you can get the sense stream to userspace.

19:00 <\[m]> <flokli> "https://github.com/AsahiLinux/..."; <- I read about this on their blog and it was like WHOA, then I am playing music on it and am like, mmmediocre

19:00 <\[m]> also didn't know it was in rust, only read their whatever bootloader was written in rust to be memory safe

19:01 <\[m]> oh it's seperate from the speaker drivers mm

19:02 <flokli> \[m]: speakersafetyd keeps observing the levels, doing it's calculation on temperature, and reports to the kernel it's ok while it is

19:02 <flokli> The kernel cuts the volume down drastically if the heartbeats stop

19:03 <flokli> Some of the kernel drivers are in rust too, not sure about that specific part

19:04 <abby> gpu, i believe

19:05 <\[m]> does that mean it will play more silently when under stress for a while?

19:06 <\[m]> I'm testing loudness now - I never cranked the speakers up on mac os so don't know but it does seem like 90 95% feels like ohoh almost too loud have to watch out but still fine

19:06 <\[m]> oh ok cool

19:07 <\[m]> who are these people getting so motivated to write shit from scratch for apple hardware huh haha

19:07 <\[m]> where's the thinkpad fanpeople

19:08 <abby> whinging about how lenovo is ruining the thinkpad name, probably

19:09 <\[m]> tbh the user experience feels crisp

19:09 <\[m]> x220 keyboard was the bad 😭 hahaha

19:09 <\[m]> not

19:10 <\[m]> did the x13s get cheaper over time? I think I bought in after a year of the release

19:10 <\[m]> and it wasn't cheap anyway

19:10 <HdkR> Probably one of Lenovo's eternal "sales"

19:11 <\[m]> 1.7k

19:11 <HdkR> I got each of my 32GB ones for around $1.5k

19:11 <JensGlathe[m]> I bought July 23, ~1200 for 21BX-001

19:12 <\[m]> march 23

19:12 <HdkR> When the "sale" isn't going on then they can climb to something like $2.4k

19:12 <\[m]> but 400 nits

19:12 <HdkR> It's a tactic that Lenovo has done for decades and it's anti-consumer AF

19:12 <\[m]> so let's hope WoA fails then haha, the cpu should be good for couple of years

19:13 <\[m]> powerBI says it's good hahaha

19:29 <steev> if woa fails, they aren't gonna swap to linux, they'll just say it's arm

19:56 <HdkR> WoA needs to survive for us to have a thriving Linux ARM ecosystem outside of Apple

19:57 <JensGlathe[m]> when the rest of the world is running on it already...

20:08 <steev> if you want the big manufacturers to support it....

20:34 <robclark> not to diss pinebook... but pinebook is kinda what you get if you are designing hw expecting only to be able to sell to linux users. Or another way to look at it, all the windows users are subsidizing the hw design for us ;-)

20:38 <JensGlathe[m]> we should be thankful (or something)

20:40 <robclark> well, feel however you want about it.. but economies of scale and dividing the NRE costs across a larger pool of users is how we get nice hw

20:47 <JensGlathe[m]> still feels like qcom has a backup plan

21:25 <HdkR> Don't need a backup plan when your SoCs are in 90% of the USA's Android sales :P

22:01 <pstef_> all I can do with my pinebook is IRC at most. Don't know about pinebook pro

22:39 <\[m]> <robclark> "not to diss pinebook... but..." <- hot take

22:41 <\[m]> pinebook pro is good just the keyboard and touchpad are shit

22:41 <\[m]> to a spoiled user ofc