ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<qzed> ah well, it's late here... so that's an issue for tomorrow
<steev> qzed: oh
<steev> you might need the lpg fix from bamse
<qzed> steev: thanks! sounds like that could be it, I'll give it a try tomorrow
<clover[m]> putting together a wiki article on getting FEX working with alarm
<HdkR> "install the AUR package, run FEXRootFSFetcher. Wrap program execution in FEXBash or FEXInterpreter"
<clover[m]> im going to be using an arch linux chroot
<clover[m]> arch linux x86_64*
<HdkR> Ideally I just get my build scripts setup to provide that through FEXRootFSFetcher
<HdkR> Getting an everything mesa build is usually not too nice for users
Evaia63101 has quit [Quit: Hack the Gibson]
agl7 has joined #aarch64-laptops
Evaia63101 has joined #aarch64-laptops
<clover[m]> im guessing unbreak_chroot.sh/break_chroot.sh have to be tweaked as well
<HdkR> Probably
<clover[m]> file /lib/aarch64-linux-gnu
<clover[m]> /lib/aarch64-linux-gnu: cannot open `/lib/aarch64-linux-gnu' (No such file or directory)
<clover[m]> can't find this on my arch host
<HdkR> That's because ALARM/Arch doesn't support multiarch
<HdkR> Can remove it, just know that chrooting in to it using FEX won't work
<clover[m]> :(
<clover[m]> tried changing to
<clover[m]> sudo mount --rbind /lib/gcc/aarch64-unknown-linux-gnu $SCRIPTPATH/lib/gcc/aarch64-unknown-linux-gnu
<clover[m]> which is where glibc is. no more errors but still cant chroot
<HdkR> clover[m]: You need the dynamic linker in the correct location as well
<HdkR> ldd `which FEXInterpreter` to get what the paths should be on Arch
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<clover[m]> linux-vdso.so.1 (0x0000007f8e3a1000)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/utpuSoMITNjXrdfPkJkBsqqT>)
<HdkR> As expected, it's just in `/usr/lib/` because of no multiarch support.
<HdkR> You could bind those files to some directory and set LD_LIBRARY_PATH but things that overwrite that will break
<HdkR> Theoretically RPATH/RUNPATH ELF things could avoid the environment variable fails, but that is hardcoding badly in a different way.
<HdkR> But really this is just working around the problem that Arch doesn't support multiarch. So maybe they should just fix that instead?
agl7-x13s has joined #aarch64-laptops
<clover[m]> the way asahi lina has it is she is using an x86 box plus her arm laptop. when she needs to make a change she updates the chroot on her x86 machine then rsyncs it to a chroot on the arm laptop
<HdkR> Yep, that's the easiest way of doing it
<HdkR> Since without multiarch support in the chroot, you would need a static linked FEX (or qemu) which has its own problems.
<HdkR> If the Linux kernel was cool enough to support binfmt_misc namespaces, then we could provide a static linked fex-emu provided specifically for chroots in that vein.
agl7-x13s has quit [Quit: Leaving]
iivanov has quit [Quit: Leaving.]
schaeffer_ has joined #aarch64-laptops
schaeffer has quit [Read error: Connection reset by peer]
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
<vkoul> steev: I should be able to send update soon and hopefully bamse can merge it for next window
jhovold has quit [Ping timeout: 480 seconds]
<qzed> steev: cheers, the lpg fix did the trick
<xnox> who is agl7-x13s? and can they please email me? or stay connected?
<xnox> they keep popping in and asking thing out of hours
<xnox> @agl7 @agl7-x13s => there is no need to rebuild ubuntu-concept iso (as doing that will require a lot of time, and installer validation) the installs it produces are still fully upgradable, with apt full-upgrade twice brings all the enchancements done since the iso was made. (i.e. gl accelerated firefox)
iivanov has joined #aarch64-laptops
<agl7> xnox: Ok. Thanks!
* agl7 is the same user like agl7-x13s
laine has joined #aarch64-laptops
iivanov has quit [Quit: Leaving.]
<robclark> akaWolf0: btw, re chrome/ium v4l2 video.. looks like at least parts of it depend on chromeos.. but not sure how hard of a dependency that is.. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/media/gpu/v4l2/BUILD.gn#75
<robclark> also looks like vaapi vs v4l2 is a compile time decision: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/media/gpu/BUILD.gn#103
<robclark> sounds like someone was doing some work to enable building v4l2 support outside of CrOS.. I'll try to find out some more details a bit later
<robclark> srinik, vkoul: ^^^ maybe chrome/ium v4l2 vid enc/dec is a thing one of you is interested in?
<srinik> robclark: yes this is something that we wanted to try on x13s..
<robclark> ok.. conveniently I sit next to some CrOS video folks.. so I can try to find out more
abcdw_ has joined #aarch64-laptops
krzk has quit [Quit: leaving]
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<leezu> robclark, srinik: chromium v4l2 linux support is pending https://chromium-review.googlesource.com/c/chromium/src/+/3380426
<leezu> to be more specific. Above ticket contains some reports from Stefan back in 09/2022 about remaining issues
<leezu> Would be great if you can reconcile those with the CrOS video folks :)
<robclark> so that CL looks like it is about splitting the code between what depends on upstream kernel v4l2 vs stuff that depends on downstream kernel patches... AFAIU for mtk there is some stateless av1 (I think?) related uabi required, but this hasn't been merged upstream because there is no upstream driver using it
<robclark> so it isn't _directly_ linux support.. but probably is a required first step and points you in the right direction
<steev> hm
<steev> srinik: any idea what i might be missing with audio on 6.4-rc2? https://github.com/steev/linux/tree/lenovo-x13s-v6.4-rc2-noaudio this is with the proper lpasscc driver. dropping the 2 patches in 6.3 and using them works, but 6.4 does not
<steev> dropping the 2 patches that were lpasscsr
<steev> using them -> the proper lpasscc driver
<steev> http://sprunge.us/QbCdh0 is the 6.4 kernel config i'm using, in case maybe i'm just missing some dependency somewhere, but alsaucm listcards shows our audio device, and "playing" audio, shows something on the meters, but no output from the speakers
<leezu> steev: Would you mind trying to enable the various Remoteproc drivers config options next time you recompile and let me know if you see the /dev/adsprpc-smd /dev/cdsprpc-smd devices?
<leezu> Or perhaps the two devices already show up with your existing config based on CONFIG_QCOM_FASTRPC=y. If so, no need to change anything. It would be helpful if you can check
<steev> i do not get the -smd devices, no
<leezu> I see. Thank you for checking. Do you see any /dev/fastrpc-* devices?
<steev> one moment
<steev> all i get is fastrpc-cdsp{,-secure}
<leezu> That's great. So cDSP driver is working on sc8280xp
<HdkR> Huh, that's a new issue. The cursor froze in place
<HdkR> Oh neat, finally got the X13s to thermally throttle