ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
chrisl has joined #aarch64-laptops
<craftyguy> does anyone know what this 70MB "Persisted_Capsules.bin" file is all about that Lenovo's FW keeps dropping into my ESP on the x13s?
<abby> iirc that's how efi firmware updates work
<abby> put the new fw in that file, set an efivar, reboot
chrisl has quit [Ping timeout: 480 seconds]
<craftyguy> is there any known way to disable this? it always seems to generate this file on boot, and it's taking up valuable ESP space :'(
sally has quit [Remote host closed the connection]
sally has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<robclark> steev: re: stacking laptops it comes down to the placement of the lid switch.. identical laptops are problematic.. random laptops comes down to luck
davidinux is now known as Guest348
davidinux has joined #aarch64-laptops
Guest348 has quit [Ping timeout: 480 seconds]
norwoodites has joined #aarch64-laptops
pinskia has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hightower4 has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
tobhe has quit [Ping timeout: 480 seconds]
derzahl has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Ping timeout: 480 seconds]
<dgilmore> tobhe_: yes it is fedora
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: Leaving...]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<steev> robclark: admittedly it has been a while since i had the same ones, but i used to do it with the c630 the most (because they're so ridiculously thin :D )
<steev> then i sold one to gwolf :D
indy has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
sally is now known as Guest383
sally has joined #aarch64-laptops
Guest383 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
norwoodites is now known as pinskia
jhovold has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
indy has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Remote host closed the connection]
abelvesa has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
noisycoil[m] has joined #aarch64-laptops
<noisycoil[m]> Hi all. For anyone interested, upstream Tor Browser can now cross-build Tor Browser nightlies for linux-aarch64 from linux-x86_64
tobhe_ is now known as tobhe
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<abby> noisycoil[m]: does that mean torbrowser-launcher supports aarch64 now?
<abby> well, linux aarch64, it already does android
<noisycoil[m]> abby: No, not yet. But I expect it will at some point. First step was to merge the code to build the browser, and this is done. Then nightly will be released (soon), then alphas and finally stable releases. Then torbrowser-launcher should support linux-aarch64
<abby> cool
<noisycoil[m]> If it doesn't I'll work on it, but it's to soon at this time
<noisycoil[m]> *too
<noisycoil[m]> abby: FYI torbrowser-launcher is broken on linux-aarch64 (that is, the torbrowser-launcher application itself, not the browser)
<noisycoil[m]> So yeah, work is needed anyway
<noisycoil[m]> Well, broken. PyQt5 is not distributed pre-compiled for linux-aarch64. This doesn't mean that someone didn't get it to work, just that it doesn't work out-of-the-box
<abby> should be fine on distros that build pyqt5 themselves
<noisycoil[m]> Yes, that's exactly what I was thinking
<deathmist> probably should start thinking about moving to Qt6 these days ;)
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> torbrowser-launcher does seem to be in the archlinuxarm repos
<SpieringsAE> does seem like quite an old build though, mayb 3rd
<SpieringsAE> may 3rd*
<SpieringsAE> huh that is actually up to date nvm
<abby> i need to switch to the right upstream for torbrowser-launcher on void
<abby> could the old tags get migrated to the new upstream (if you're a dev)?
<SpieringsAE> I should try out void at some point
<SpieringsAE> it doesn't use systemd as init or something right?
<abby> correct, it's runit
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<noisycoil[m]> <deathmist> "probably should start thinking..." <- Yeah
<noisycoil[m]> BTW, torbrowser-launcher seems to work fine on arm64 with distro packages. x86 is hardcoded so small changes are needed for when stable arm64 tarballs will be release. This is very easy to fix. Will submit a MR in due time
<noisycoil[m]> <SpieringsAE> "torbrowser-launcher does seem to..." <- This is likely true, but it will still download the x86 browser
<SpieringsAE> it seems to be an unpatched arch pkgbuild so I guess yeah
pinskia has quit [Read error: Connection reset by peer]
pinskia has joined #aarch64-laptops
wizzard has joined #aarch64-laptops
martiert has quit [Read error: Connection reset by peer]
martiert has joined #aarch64-laptops
SpieringsAE has quit [Quit: Leaving]
<macc24> (not so) fun fact: you can fry the wsa8845 speaker amplifiers by just mucking around in alsamixer
<macc24> s/amplifiers/controllers/
<konradybcio> macc24 reminds me of that time someone contributed cirrus-logic-audio-amp-as-an-ohmmeter to asahi..
<noisycoil[m]> torbrowser-launcher patched for linux-aarch64 at https://gitlab.torproject.org/NoisyCoil/torbrowser-launcher/-/tree/linux-aarch64, but of course it's fully untested given that there are no stable releases yet (and there won't be for quite some time)
chrisl has joined #aarch64-laptops
<abby> \o/
deathmist1 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
deathmist has quit [Ping timeout: 480 seconds]
Caterpillar has joined #aarch64-laptops
deathmist has joined #aarch64-laptops
deathmist1 has quit [Ping timeout: 480 seconds]
<agl> steev: Your kernel 6.12 works very well!
<jhovold> macc24: sorry to hear that, but yeah, unfortunately that is currently possible
<jhovold> which was machine was this again?
<jhovold> and have you verified that the issue remains in windows?
<macc24> lenovo yoga slim 7x
<macc24> yes it's still broken in windowa
<macc24> windows*
<jhovold> that sucks
<jhovold> we had some users of the x13s thinking that they had blown their speakers, but it turned out to be a codec bug that increased the digital gain on every boot until everything was distorted
<jhovold> fixing the bug and clearing the alsa state fixed that
<jhovold> we really should get some volume limits in place also on x1e before enabling sound on more devices
<jhovold> still hesistant to go down to audio rabit hole again with my t14s
<tobhe> yes, I was going to ask if there are any at all at the moment
<jhovold> no limits at all on x1e currently
<jhovold> so make sure you keep that volume down, and tell all your (ubuntu) users to do so too
<jhovold> or better yet, don't throw in audio patches that are still work-in-progress in you concept image until such issues have been addressed
<jhovold> go down *the* audio rabit hole again...
<tobhe> yep, that is why I'm asking. Currently there is no way to enable it by accident as we don't ship any topology firmware
<jhovold> that's good
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
anozetsubou has joined #aarch64-laptops
user_anoz has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Quit: alfredo]
<JensGlathe[m]> argh
<JensGlathe[m]> 6.12 build greeted me with a blank screen
<JensGlathe[m]> After some debug the clue was that the retimer regulators are switched off at ~30s. I had this already. PS8830 driver mutated to PS883x, updating config helps (I guess)
<jhovold> it should, yes :)
<JensGlathe[m]> the Ubuntu Config config as in qcom-x1e takes 40mins to build, on x1e
<JensGlathe[m]> Concept*
<tobhe> it isn't exactly optimized for build speed. but 40 mins is not too bad :)
<steev> agl: thanks for the confirmation
chrisl has joined #aarch64-laptops
<tobhe> creemj:
<tobhe> meh, wrong window
krei-se has quit [Ping timeout: 480 seconds]
<jhovold> JensGlathe[m]: johan_defconfig clocks in under 2 minutes on the T14s
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> yep
<jhovold> a bit more practical for development
<ppd[m]> jhovold: I've been kinda diving into the audio on the Yoga. I've found the audioreach repos from QCOM, but I'm not sure if this is the thing I need in the first place. Any ideas from you?
krei-se has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<jhovold> ppd[m]: hopefully we'll be able to enable the speakerprotection available in the dsp at some point, but until then I think we need to set some hard volume limits for the speakers as I did for the x13s
<jhovold> it's not perfect, but better than toasted speakers
<ppd[m]> jhovold: wait, the adsp in the soc has speaker protection?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> now 6.12 also has screen
<JosDehaes[m]> the tplg file for yoga was merged in https://github.com/linux-msm/audioreach-topology
<JosDehaes[m]> ppd: I wrote about speakers here: https://gist.github.com/joske/45386018b6b5cc04d0390dc96ce402af
<JensGlathe[m]> 6.12 with Ubuntu qcom-x1e packaging is [up](https://drive.google.com/drive/folders/1w0UCUSDsEDXc4sN9lpB5EViuWNnLEMdo?usp=drive_link)
<JensGlathe[m]> It has the most complete T14s dtb I could find
<JensGlathe[m]> Untested by me though, no hw
<macc24> if only there was a place where you could submit devicetree additions and everyone could benefit from them
<ppd[m]> Jos Dehaes: Yes, I read that. The issue is the audioreach repo stuff that someone brought up a few days ago and the speaker limits.
<macc24> probably https://github.com/AsahiLinux/speakersafetyd could be used
<JensGlathe[m]> anonymix007 has a repo. Ideally it should be upstream, but that is quite a process
<ppd[m]> macc24: the issue with that (currently) is the lack of parameters to model the speaker
<JensGlathe[m]> Oh and Ubuntu Concept x1e has pretty current ones
<ppd[m]> Now, is it possible that those parameters could be extracted using the audioreach tools? Yes, it is, but I have no idea if they actually do exist in the adsp db file.
alfredo has joined #aarch64-laptops
<wizzard> @tobhe Thanks for the how build your own ubuntu concept x elite kernel guide
<JensGlathe[m]> Oh nice
<tobhe> wizzard: welcome! I'll try to add one for building images too. But first I need to improve the tooling a bit
<macc24> i have opened the graph in qact and have no idea what i'm doing
<macc24> i see "speaker protection v5" thing
<macc24> no speaker parameters tho
todi has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Remote host closed the connection]
alfredo has joined #aarch64-laptops
todi has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
hightower4 has quit [Ping timeout: 480 seconds]
steveej[m] has joined #aarch64-laptops
<steveej[m]> is there any chance we get HW virtualization support on x13s within a couple of months?
alfredo has quit [Quit: alfredo]
<macc24> there's slbounce which can get you kvm
<steev> doubt it'll be only a couple of months
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
<craftyguy> is that a question for qualcomm? :P
<robclark> I mean, slbounce already works on x13s
<robclark> unless the question is when we get HW virt _and_ all the random things that depend on qc's el2 at the same time (and in that case, I think the answer is we have to use gunyah
<ppd[m]> macc24: are there *any* parameters?
jhovold has quit [Ping timeout: 480 seconds]
<steev> i guess i don't really count slbounce on the x13s since you have to choose between battery charging and kvm
<craftyguy> the battery mostly charges for me, I mean I have no clue what level it's currently at when in el2, but I can go days without powering off if I leave it plugged in :P
<craftyguy> but yes it would be nice if we could have a more functional system in el2
<craftyguy> I keep seeing references to "use gunyah" but I have no clue how to do that as a long-time libvirt/kvm/qemu user
<craftyguy> is there some doc you'd recommend for how to use it exactly for running VMs on the x13s?
<robclark> I don't think kernel patches for gunyah went anywhere.. and no idea if anyone has written qemu patches (I guess not).. But I think crosvm does have gunyah support.. I assume this is what QC is planning to use for upcoming android pkvm requirement
<Dylanger> <macc24> "there's slbounce which can get..." <- slbounce looks v promising
<anonymix007[m]> robclark: there are some qemu patches: https://lists.nongnu.org/archive/html/qemu-arm/2024-05/msg00287.html
<anonymix007[m]> There are also patches for qemu 8.1.1 from the "Starting Windows VM on SM8650" document. Don't ask me how I got access to it.
<robclark> ahh
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]