02:19 <altacus> jhovold: Thanks for the s3 info. Very glad to hear that there's still room for improvement for the idle battery time. Hibernation would be a great alternative to s3 idle.

02:19 <altacus> I'm guessing there's virtually no chance that Qualcomm will add s3 to their firmware,

02:22 <altacus> jhovold: Thank you for the wiki! It really does answer so many of my questions!

04:03 <craftyguy> it is common that qualcomm SoCs don't do S3?

05:05 <travmurav[m]> craftyguy: altacus don't think you even /need/ s3 on qcom (or even on arm in general), the sleep model is different

05:06 <travmurav[m]> i.e. s2idle on 7c1 aspire1 is ~10 days of suspend from full battery (~0.2W iirc)

05:06 <travmurav[m]> but to elaborate

05:07 <travmurav[m]> based on my knowledge of ~10 years old qcom platforms + some educated guesses the sleep works like this:

05:10 <travmurav[m]> when Linux wants to cpuidle, it decides how deep the idle level it can use considering the entry/exit latency. for s2idle the deepest level will be picked. then the firmware is notified of the level via PSCI and linux executes WFI (wait-for-interrupt) instruction. Then <implementation defined> the device waits for the interrupt, and when it arrives, the device is resurrected and returned to Linux

05:11 <travmurav[m]> on qcom 10 years ago, the act of setting idle level would pick a "program" in special hardware blocks that run when WFI is executed. I doubt this has changed much

05:13 <travmurav[m]> and that program would perform actions like gating off cpu clocks, disabling core power regulator etc

05:14 <travmurav[m]> so in the "best" case when you find yourself in the middle of the WFI, the cpu core is dead, unpowered; the ram is in self-refresh; and the only thing running in the soc is the small "aon" core that is waiting on an interrupt to wake everything up

05:14 <travmurav[m]> which would practically be s3 I guess

05:16 <travmurav[m]> so for x13s to make use of that, one would need to make sure there is nothing interfering with the idle entry, since if some hw block is in use, it can inhibit it

05:19 <travmurav[m]> i.e. afaict on x13s the asoc boardfile doesn't disable clocks when the sound is not used anymore, so you would never get to a really low idle where all remoteprocs are dead, given you still seem to boot with clk_ignore_unused, there will be more stuff like that

05:35 <craftyguy> thanks for the explanation. ya I wasn't implying that S3 was needed. I have a lot of experience on x86, where S3 is (or was) pretty common, so I was curious about it here

09:37 <travmurav[m]> (thinking a bit, seems like I mixed up PSCI an pre-psci paths, the wfi remark is somewhat wrong then)

12:40 <chenxuecong> how can I fix invalid framebuffer when booting linux

12:43 <Jasper[m]> chenxuecong: What platform/device

15:04 <chenxuecong> HUAWEI MateBook E go

15:04 <chenxuecong> with sc8280xp

15:05 <chenxuecong> thanks

16:48 <clover[m]> steev: just got back from nola for a bach party, what linux version are we on now?

16:48 <Bioxvirizm-x13s[m]> clower last update with you repository mutter broke system=\

16:49 <clover[m]> are you using gnome bioxvirizm?

16:49 <steev> i believe 6.5.7? i have some new stuff (pulling in some of the sound fixes from johan's latest push) but something seems off and i'm getting failed boots

16:49 <Bioxvirizm-x13s[m]> clover[m]: yes 45

16:49 <steev> probably a newer mutter with gnome 45?

16:50 <Jasper[m]> steev: HMMMM failed boots how?

16:50 <clover[m]> sorry about that, i just pushed a new one about 5 minutes ago, try using the recovery version and updating

16:50 <clover[m]> the recovery disk i mean

16:50 <clover[m]> i have to carry mutter because of the patch it needs for edp

16:50 <Bioxvirizm-x13s[m]> steev: mutter was version 45

16:51 <steev> Jasper[m]: that i do not know because i stupidly don't make the boots verbose, just at the point it should load gdm, it reboots instead :)

16:51 <steev> that and, i haven't had time to reboot to research it as i'm working on some things for work

16:51 <clover[m]> Bioxvirizm-x13s: make sure to disable gdm and start it manually until you know it's fixed

16:52 <Bioxvirizm-x13s[m]> I have an iso with the latest ubuntu, if I boot into the live sd, supposedly I can roll back the app? I just don't understand how yet)

16:52 <Jasper[m]> steev: @[(⊙_◎)] sounds similar to what we're having

16:53 <clover[m]> Bioxvirizm-x13s: just use the archiso, mount and arch-chroot into your root partition, and then fix it from there

16:53 <steev> for me, it's just with the asoc and regmap fixes applied

16:53 <clover[m]> not super sure why your mutter didn't work though, booted just fine here so its a bit concerning

16:54 <clover[m]> try a pacman -Syu to make sure you have all latest packages

16:54 <Bioxvirizm-x13s[m]> It's good to have a desktop computer)

16:55 <Bioxvirizm-x13s[m]> clover[m]: I update x13 every day)

16:56 <clover[m]> still try it because i pushed mutter a few times today

16:56 <clover[m]> make sure you have mutter 45.0+r57+g909cc6c24-0

16:56 <Bioxvirizm-x13s[m]> So I'm lucky) your arch has been living with me since spring.

16:57 <Bioxvirizm-x13s[m]> lived)))

17:01 <clover[m]> steev: to clarify, is what is in your 6.5.y branch safe to use or are there currently booting issues with it

17:01 <steev> clover[m]: it's safe, i don't push things (without saying so) if they aren't reliably booting

17:01 <clover[m]> Bioxvirizm-x13s: 0 bytes ...

17:02 <Bioxvirizm-x13s[m]> interestingly the mutter file is 0 bytes in size. The computer just shut down during installation.

17:02 <steev> that would definitely cause mutter issues :D

17:02 <clover[m]> steev cool

17:02 <Bioxvirizm-x13s[m]> steev: do you think?)

17:04 <Bioxvirizm-x13s[m]> clover: can i ask you from bin/ to send me the mutter file?

17:05 <clover[m]> ➜ ~ md5sum /usr/bin/mutter

17:05 <clover[m]> f0ac3838617249188ac22d8318ee6341 /usr/bin/mutter

17:06 <Bioxvirizm-x13s[m]> It's also 0 bytes.

17:07 <clover[m]> just do a sudo pacman -S mutter, you should get what i have, without having to manually copy binaries

17:08 <Bioxvirizm-x13s[m]> iso takes forever to download, I booted into Ubuntu.

17:08 <clover[m]> i see

17:10 <Jasper[m]> Bioxvirizm-x13s[m]: Not trying tty?

17:11 <clover[m]> dm'd bioxvirizm the binary

17:20 <clover[m]> keep a spare iso on a thumb drive and shove it in a drawer, then you can quickly fix your arch system if or when it breaks

17:24 <steev> you can chroot into an arch system from an ubuntu one

17:27 <clover[m]> havent tried

17:28 <steev> a chroot is a chroot

17:28 <clover[m]> i figured arch-chroot did some fancy or extra stuff behind the scenes

17:28 <steev> it probably does the mounts

17:30 <HdkR> FEX's x86 rootfs setup chroots from Ubuntu in to Arch. It works okay

17:45 <enyalios> i actually do all my gentoo updates while chrooted in from my ubuntu install

17:45 <enyalios> i still want my sound working while im compiling all my updates

17:46 <clover[m]> nice

17:47 <clover[m]> how is gentoo on an x13s?

17:50 <enyalios> it works great except i cant get the sound working still

17:50 <enyalios> its very frustrating

17:51 <enyalios> i just need a big block of time to compile the kernel a bunch of times to test different versions and different configs

17:51 <enyalios> and recompile pipewire a bunch with different options

17:51 <enyalios> but its hard to have a lot of time with kids, especially a small one

17:51 <enyalios> so ive just been using ubuntu mostly, which works very well

17:52 <enyalios> i think i have everything working in gentoo that works in ubuntu except for audio

17:54 <clover[m]> do you have pd-mapper?

17:55 <clover[m]> i guess if your battery charge status is working then you have pd-mapper, but i think that also somehow affects sound

17:55 <enyalios> yes

17:56 <enyalios> i couldnt get any sound at all with bare also

17:56 <clover[m]> are you using a steev kernel with laptop_defconfig?

17:56 <enyalios> with pipewire i can get sound sometimes

17:56 <enyalios> but it stops working with no error messages that i can tell

17:56 <enyalios> yes steev's 6.5.3 with laptop_defconfig

17:57 <enyalios> alsa-ucm-conf with that extra pull request patched in

17:57 <enyalios> the latest linux-firmware version from gi

17:57 <enyalios> t

17:57 <enyalios> alsa-ucm-conf is 1.2.10

17:58 <clover[m]> i am using the srini's alsa-ucm-conf on his x13s-volume-fixes branch

17:58 <enyalios> i believe i tried that too, but steev said to use the packaged one with the extra pull request

17:58 <enyalios> which distro are you on?

17:59 <clover[m]> endeavourOS

17:59 <enyalios> as far as my googling shows, sound *should* be working

17:59 <enyalios> but its not, so im pretty sure its a configuration issue or something

18:00 <clover[m]> basically arch but purpler

18:00 <enyalios> lol :-)

18:00 <enyalios> arch has always seemed very appealing too

18:00 <enyalios> but ive been on gentoo for like 20 years and really love it

18:01 <enyalios> plus no systemd makes me very happy

18:01 <enyalios> if you like purple, you should check out gentoo

18:01 <enyalios> its very purple too

18:01 <enyalios> ;-)

18:01 <clover[m]> haha

18:02 <clover[m]> well, let us know if you ever figure out sound

18:04 <enyalios> will do

20:45 <Jasper[m]> OH CRAP I JUST SAW ERROR LOGS FOR THE HANG I'VE BEEN GETTING

20:45 <Jasper[m]> Couldn't take a pic in time

20:45 <Jasper[m]> It was an ARM-SMMU hang

23:53 <altacus> travmurav: Thank you so much for that in depth overview of idle states with linux. I'm still re-reading it to fully absorb it.