steev changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Various Snapdragon laptops) - WIP kernel: https://gitlab.com/Linaro/arm64-laptops/linux/-/commits/qcom-laptops - Chat archives: https://oftc.irclog.whitequark.org/aarch64-laptops
<steev> rigo: fwiw, i used in kernel pd mapper with c630 as soon as it was available and cannot recall ever having issues with it on my c630
notHorseface has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
alexeymin has quit [Ping timeout: 480 seconds]
alexeymin has joined #aarch64-laptops
alexeymin is now known as Guest15483
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Remote host closed the connection]
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
<HdkR> Was there someone in here creating a downstream rootfs image for FEX?
<HdkR> valpackett maybe?
<HdkR> whomever it was will want to stick a graphics_provider.json file in the root of the image like I'm doing for the upstream images. Ubuntu file for example: https://github.com/FEX-Emu/RootFS/blob/main/Scripts/Ubuntu_24_04/graphics_provider.json
<HdkR> This'll let the SteamLinuxRuntime be able to find x86 graphics libraries for FEX.
<valpackett> no, I *never* used a rootfs with fex, always rootfs-less
<HdkR> valpackett: Ah okay
<HdkR> Not sure how that's going to end up working with arm64 steam, but...yolo I guess
<notHorseface> I would still choose the sane box.
<notHorseface> but only becuase I AM NOT DEAD OR MISERABLE.
<HdkR> :thonk:
<valpackett> not sure why arm64 steam would need any intervention? o.0
<valpackett> proton has everything already wrapped inside? i rebuilt a new proton git version with their build system and it just worked?
<HdkR> valpackett: Aye, Proton arm64 doesn't need any x86 libraries. But Linux x86 apps do (Or Proton non-arm64ec)
<HdkR> valpackett: Today's client update can finally launch things using the integrated FEX-Emu tool :)
<valpackett> oh, they've added fex to steamRT itself to run native linux games?
<HdkR> https://steamdb.info/app/3127680/ It's technically a freestanding app
<HdkR> app/tool
hexdump01 has joined #aarch64-laptops
<HdkR> I need to update FEX's wiki guide for Steam to ensure everyone is setting it up correctly.
<valpackett> mmm
hexdump0815 has quit [Ping timeout: 480 seconds]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
<travmurav[m]> oh compat list was finally published it seems, nice
<travmurav[m]> and require_tool_appid finally works for rt4 hooray
<HdkR> yeppers
<travmurav[m]> and cool seemingly nothing broke compared to manually relaunching in pv (except everything being broken because I broke things)
<HdkR> Yea, that bit still needs to be solved. Steam itself needs to launch in a runtime someday
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
flto has quit [Remote host closed the connection]
flto has joined #aarch64-laptops
jhugo has quit [Read error: Connection reset by peer]
rz_ has quit [Remote host closed the connection]
jhugo has joined #aarch64-laptops
konradybcio_ has quit [Read error: Connection reset by peer]
konradybcio_ has joined #aarch64-laptops
ldts has quit [Read error: Connection reset by peer]
rz has joined #aarch64-laptops
ldts has joined #aarch64-laptops
proycon has quit [Ping timeout: 480 seconds]
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
antoinelassagne0 has joined #aarch64-laptops
antoinelassagne has quit [Read error: Connection reset by peer]
antoinelassagne0 is now known as antoinelassagne
bandini has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
dc7800 has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
pabs has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
rz has quit [Ping timeout: 480 seconds]
pankpati has quit [Read error: Connection reset by peer]
sumits has quit [Read error: Connection reset by peer]
rz has joined #aarch64-laptops
<maz> first time I see an actual price for this box, but that's a bit... excessive...
<steev> a wee bit
<steev> thanks ai bros
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
<JensGlathe[m]> fuu
<JensGlathe[m]> bought the x1 mini (32GB, 512) for GBP300-ish
proycon has joined #aarch64-laptops
Ariadne_ has quit [Read error: Connection reset by peer]
pankpati has joined #aarch64-laptops
<maz> JensGlathe[m]: yup, I now have two of those, great little box.
<maz> I'll see if I can get hold of the X1P version next time I have to cross the pond...
Ariadne has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> HdkR: How does one use the new FEX steam tool. I installed it, but I guess I need to add something to the launch options? Want to try running factorio through it insteam of using the windows version with proton
<HdkR> SpieringsAE: Need to set an environment variable to one of FEX's rootfs graphics_provider.json files
<HdkR> eg: STEAM_COMPAT_GRAPHICS_PROVIDER=/home/ryanh/.fex-emu/RootFS/Ubuntu_24_04/graphics_provider.json
<HdkR> I updated the Ubuntu 24.04, Fedora 44, and Arch images yesterday to include them.
<HdkR> Then when you launch the game, Steam's FEX tool will automatically pick it up.
<HdkR> er, also should say that when executing a Linux x86 game, Steam will automatically use FEX as long as you're on the August 11th beta client.
gwolf has quit [Ping timeout: 480 seconds]
<travmurav[m]> HdkR: somehow I assumed steam would like install both x86 and arm steamrt and use those for fex rootfs
<travmurav[m]> I guess gpu driver still come from the host
<SpieringsAE> HdkR: hmm, I've let the client auto update but factorio is not launching
<SpieringsAE> "cannot execute binary file"
<SpieringsAE> ah so I have to provide the fex rootfs myself?
<HdkR> SpieringsAE: Help -> About Steam will tell you the client build date
<HdkR> Yea, FEXRootFSFetcher can help you download plus extract them as per usual.
<SpieringsAE> yaeh aug 11
<HdkR> Then that environment variable points to the json file in the root of the rootfs
<HdkR> travmurav[m]: It does install both x86 and arm steamrt. Just still needs graphics drivers from an x86 rootfs.
<travmurav[m]> right I see, that makes sense I guess
<travmurav[m]> since rt doesn't ship that afaik, yeah...
<HdkR> yep
* travmurav[m] waves hands at novideo
<HdkR> I think for spark you can rip the drivers from an x86 package and it works or something. Haven't tried.
<travmurav[m]> (though it probably makes a lot of sense with mesa too)
<travmurav[m]> to not ship it in rt
<HdkR> Yea. It's a deliberate decision not to ship video drivers in the RT
SpieringsAE has quit [Quit: SpieringsAE]
<valpackett> should be easy enough to make such a file for x86 flatpak runtimes..
dc7800_ has quit [Remote host closed the connection]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
jelly has quit []
jelly has joined #aarch64-laptops
Caterpillar has quit [Ping timeout: 480 seconds]
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
psydroid|2 has joined #aarch64-laptops
jelly has quit [Remote host closed the connection]
dc7800 has quit [Quit: ZNC 1.10.1 - https://znc.in]
dc7800 has joined #aarch64-laptops
jelly has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
kalebris has quit [Read error: Connection reset by peer]
kalebris has joined #aarch64-laptops
psydroid|2 has quit []
psydroid|2 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
Caterpillar has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
Caterpillar has quit [Ping timeout: 480 seconds]
psydroid|2 has quit []
psydroid|2 has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
martiert_ has joined #aarch64-laptops
martiert has quit [Ping timeout: 480 seconds]
Caterpillar has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
Caterpillar has quit [Remote host closed the connection]
tobhe has joined #aarch64-laptops
psydroid|2 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Remote host closed the connection]
psydroid|2 has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
bandini has quit [Quit: WeeChat 4.9.5]
psydroid|2 has quit [Ping timeout: 480 seconds]
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
psydroid|2 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
psydroid|2 has quit []
pabs has quit [Read error: Connection reset by peer]
pabs has joined #aarch64-laptops
psydroid|2 has joined #aarch64-laptops
psydroid|2 has quit [Ping timeout: 480 seconds]
kalebris has quit [Ping timeout: 480 seconds]
kalebris has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
<programmerin-wonderland[m]> The Chromebook bluey (hamoa) seems to be confirmed now.... There's one HP model (Googlebook 14c) but it's not a Chromebook but a Googlebook. I hope they're not too closed off
psydroid|2 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<programmerin-wonderland[m]> <JensGlathe[m]> "No real idea, shouldn't. 7.1.7..." <- I mainly just rebase whenever Ubuntu concept rebases But I'm thinking about just going off of mainline now
programmerin-wonderland has joined #aarch64-laptops
<programmerin-wonderland[m]> <valpackett> "should be easy enough to make..." <- Oh is there any way to run x86 flatpaks on arm with FEX yet or are we still not in that era
<programmerin-wonderland> actually, I just saw your codeberg LOL https://codeberg.org/valpackett/fexwrap
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
psydroid|2 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
<weirdtreething> just got my x2ee zenbook a16
psydroid|2 has joined #aarch64-laptops
psydroid|2 has quit []
psydroid|2 has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
<misyl> nice
<misyl> im running the new arch arm stuff on mine
<Mis012[m]> <programmerin-wonderland[m]> "The Chromebook bluey (hamoa..." <- pretty sure they will be
<weirdtreething> misyl: alarm or the new collabora thing?
<misyl> the community build of the ports stuff mentioned here https://ports.archlinux.page/
<weirdtreething> ohh nice
<weirdtreething> have instructions for it?
<misyl> https://repo.froggi.es/ iso here if you want to play, but health warning its a bit of a pita as archinstall isn't very friendly yet
<weirdtreething> oh don't worry. it's still easier than doing everything myself
<misyl> tldr, disable universal kernel images, ONLY pick mesa (virtualbox) as thats just the mesa package and nothing else, install it somewhere then chroot in
<weirdtreething> which bootloader should i use
<misyl> add the [froggies] repo, install linux-zenbook-a16-dtbs, linux-zenbook-a16, linux-zenbook-a16-headers
<misyl> grub
<weirdtreething> don't you need grub
<misyl> yeah, use grub
<misyl> i'd copy the dtb manually also to /boot somewhere so you can manually `devicetree /zenbook.dtb` it or whatever
<weirdtreething> currently struggling to even get through windows oobe lol
<misyl> but thats the jist of it
<programmerin-wonderland> weirdtreething: your laptop boots linux to EL2 by default without any hypervisor right?
<weirdtreething> idk how you check lol
<programmerin-wonderland> just boot linux and check dmesg i guess, is your dtb in linux-next?
<weirdtreething> last time when i was helping wearr we needed to pull in some patches but it may be there now
<programmerin-wonderland> Oh wait yeah he already has the laptop, did he get linux booting yet?
<weirdtreething> he booted misyl's iso iirc
<robclark> x2* all boots EL2
<programmerin-wonderland> thats so nice
<misyl> i think linux-next is new enough for the laptop
<misyl> i've been meaning to give it a go and update my ISO but I havent had a chance to yet
<misyl> so busy with work rn >.<
<weirdtreething> checking rn
<weirdtreething> well i think there are still some useful glymur patches not in linux-next
<weirdtreething> also needed those clock patches to make the display work
<programmerin-wonderland> I really want to get one but I cant justify since I just got an X1E last year...
<weirdtreething> ok yeah the zenbook a16 dts landed in linux-next
<programmerin-wonderland> yeah
<misyl> ah yeah, i had an extra patch i needed for the display to work
<programmerin-wonderland> its also the only device X2 device with a dtb in linux-next it appears.
<programmerin-wonderland> except the crd
<weirdtreething> wait this laptop has a touchscreen
<programmerin-wonderland> did you find that out by looking at the dtb
<weirdtreething> no I was reading the patch description and it mentioned some models having a touchscreen
<programmerin-wonderland> I found out my laptop supported SD Express the same way
<programmerin-wonderland> none of the marketting materials had any mention of SD Express at all
<weirdtreething> this one has a full sized sd slot which i have not seen in a long time
<programmerin-wonderland> I think its also SD Express
<weirdtreething> probably
<programmerin-wonderland> misyl: do you have a zenbook a16 x2ee as well?
<misyl> yes thats why i made the iso for it :P
<weirdtreething> programmerin-wonderland: i was talking to them back when I was helping wearr with his a16
<programmerin-wonderland> OH
<weirdtreething> yeah check the logs on 24th july
<programmerin-wonderland> that laptop has ravaged our friend group I know like 4 people with one now because its ridiculously well priced for 48GB ram
<programmerin-wonderland> and with a good enough CPU
<weirdtreething> this is the fastest arm laptop out there right?
<programmerin-wonderland> m5 max is faster
<weirdtreething> well I'd never buy a mac lol
<programmerin-wonderland> its competitve CPU wise with m5 pro I believe and GPU wise with M5. GPU wise the drivers are ass on windows, velzie (with X2E, not EE) gets faster performance on minecraft with llvmpipe than the native OpenGL driver
<programmerin-wonderland> (well, lack of native OpenGL driver, the OpenGL --> D3D12 translation)
<Mis012[m]> mac is probably less locked down even, but there's other issues with Linux bringup on M5
<programmerin-wonderland> I doubt its less locked down, heard newer macs disable certain instructions if you try booting something not macOS and made it harder to reverse engineer for asahi team tbh but I also have zero clue what I'm talking about here
<weirdtreething> they seem equally locked down
<Mis012[m]> I'm aware, it's still less locked down than qcom :P
<programmerin-wonderland> what exactly is locked down about X2 series now that its EL2? the vendor signed firmwares requirements?
<programmerin-wonderland> sorry just trying to learn more about it LOL
<Mis012[m]> TME is locked down period, EL3 anything is locked down unless it's unfused in which case you can still only have an alternative boot chain by using JTAG
<Mis012[m]> I guess maybe unfused with JTAG glymur would be less locked down than M5, but good luck getting that in a laptop
<programmerin-wonderland> I wonder if GoogleBook bluey will have unfused EL3, heard on other Qualcomm chromebooks they had EL3 access
<weirdtreething> based on coreboot having the option to use signed blobs, it seems like they will be fused
<Mis012[m]> chromebook team had a mission statement that they won't lock shit down
<programmerin-wonderland> but what about the googlebook team :P
<Mis012[m]> see above
<weirdtreething> i wonder what will happen with the intel pantherlake googlebooks
<weirdtreething> those better not have bootguard
<programmerin-wonderland> I'll be slightly pissed if they do
<weirdtreething> Mis012[m]: what is TME?
<Mis012[m]> risc-v actual boot core
<Mis012[m]> seems to be a result of qcom giving up on the idea that SPU, normal arm cores and modem can all mutually distrust each other just by each having a separate bootrom and XPUs being used properly
<misyl> programmerin-wonderland: I am not surprised, all the DX/GLToD3D12 drivers don't seem to really be made with performance in mind
<misyl> They don't do the same level of heroics that eg. DXVK would do
<programmerin-wonderland> interestingly zink on windows also seems to kind of suck (on my X1E..) but native vulkan apps perform well
<programmerin-wonderland> and I thought zink on windows was designed with those heroics in mind
<Mis012[m]> Mis012[m]: so they added a new core that's supposed to be super duper extra secure and ensure that all the other security domains don't attack each other
<Mis012[m]> obviously this is speculation
<programmerin-wonderland> sounds a bit like nvidia GSP
<Mis012[m]> I suspect that anyone who knows for sure is under an NDA and the NDA doesn't care if there is any chance whatsoever that the information being public-ish hurts qcom
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
pabs has quit [Read error: No route to host]
pabs has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
anonymous has joined #aarch64-laptops
anonymous has quit []
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
<JensGlathe[m]> How many layers of hw security can you cram onto a chip, and how many actually make sense... It doesn't make sense to me, only if I account for MIL use
<Mis012[m]> for data security the only thing you need is FDE with a strong passphrase and a crypto setup that forces the attacker to brute force it
<Mis012[m]> a pin with TEE magic is objectively less secure
<Mis012[m]> but attestation is also useful
<Mis012[m]> the problem with attestation is that it usually uses the display, which actual bootrom code can't really do
<Mis012[m]> whole DRAM encryption is also nice
<valpackett> for data security you also need some assurance that you're not typing your fde passphrase into a fake logger screen someone put onto your disk while you left the device behind xD
<valpackett> but lots of other movement in that space is more about convenience heh
<Mis012[m]> arguably phones are not usually left unattended
<valpackett> yea and funnily enough they're more locked down against the tampering that laptops are more prone to
<Mis012[m]> and in general evil maid is considered separate in threat modeling for a reason
<Mis012[m]> but yeah, attestation is nice to have
<Mis012[m]> arguably qcom has attestation by sahara giving you the hash in fuses
<Mis012[m]> so you can check if someone changed the SoC
<Mis012[m]> or the whole device
<valpackett> the "cool" thing with all the tpm/secure-element magic is that there's now sorta working fde for regular normies who can't be arsed to invent a good passphrase
<valpackett> or not fde but file level encryption sometimes etc
<Mis012[m]> the uncool this is that it's fundamentally unsecure and it WILL be a problem
<Mis012[m]> and of course the fact that the way it's implemented has certain requirements for boot chain etc security
<Mis012[m]> not necessarily ones that conflict with self-signing, but it sure makes the whole problem more annoying to deal with
<valpackett> the systemd/particleos setup is pretty cool, it makes all that quite easy to do with self signing
<Mis012[m]> .......?
<Mis012[m]> self signing the stuff that actually matters, not .efi files
<valpackett> oh, that, well.. yeah
<Mis012[m]> which wouldn't even be present in my preferred boot chain, edk2 for sure wouldn't be anyway
<Mis012[m]> the RoT is literally the only thing that matters
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
<JensGlathe[m]> So we can agree on one layer, maybe one for convenience/bugfixing. Why do they have... more acronyms than I care to memorize?
psydroid|2 has quit [Ping timeout: 480 seconds]
<Mis012[m]> why you need separate TEE and SPU is a great question
<Mis012[m]> I guess OEMs are allowed to have trustlets
<Mis012[m]> that's why
<Mis012[m]> TME is just there to enforce the other stuff with sw because they gave up on doing it with hw afaict
<weirdtreething> misyl: it seems like your arch repo key is missing
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
<misyl> oops
<misyl> lemme fix that
<misyl> weirdtreething: Should be fixed
<weirdtreething> ok yeah looks to be there now
<weirdtreething> I just extracted the key from the live environment and imported it into the install
<misyl> 👍
<penguin42[m]> Jens GlatheI did wonder if there should be a kernel/Documentation/acronyms.txt
<Mis012[m]> but then should TME be there
<penguin42[m]> Jens GlatheCoupled with a rule that any patch that introduces an acronym should update it and at least say what it is in the commit messages; so many patch sets are 'support the splurt on gork' with only 3 people knowing what it is
<Mis012[m]> 3 people in total or 3 people who are not under an NDA so can talk about it :P
<penguin42[m]> Mis0123 people in total; 2 are under NDA, one is locked away on an island prison
<weirdtreething> the acronyms only being known under NDA is really annoying
<Mis012[m]> there's some public NIST documents on TME
<Mis012[m]> and how it's much crypto very secure 10/10 banks recommend
<Mis012[m]> don't recall if it says what it stands for, tbf it's not that important
<Mis012[m]> in this case
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
<clover[m]> <penguin42[m]> "Jens GlatheCoupled with a rule..." <- Gork finally got splurt support? Nice
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<weirdtreething> misyl: did you ever get audio working?
<weirdtreething> i can't find where i'm supposed to get the tplg from
<clover[m]> weirdtreethingdo you have alsa-ucm-conf installed?
<weirdtreething> that doesn't matter. i don't have a tplg and the kernel driver fails to probe because it's missing.
<weirdtreething> the commit which added the devicetree said that audio was working so I would assume I could find the tplg somewhere
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
<steev> weirdtreething: which device?
<weirdtreething> asus zenbook a16
<steev> hm, yeah i don't see one for that, unless someone has one in a fork - https://github.com/linux-msm/audioreach-topology is the github repo that generates (some?) of them
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<robclark> so audio works on x2 slim7x w/ CRD tplg.. idk about a16
<robclark> I think srini posted ucm (and presumably tplg)?
<misyl> weirdtreething: I have not yet, I was hoping to try again once everything lands in linux-next
<misyl> No idea if its kernel/dt side or alsa ucm side or what. Didn't dig into it
<robclark> you need (1) ucm, (2) tplg, (3) remoteproc probed and adsp started (if fw wasn't avail at the time remoteproc was probed)
<robclark> that's about the extent of what I know about audio ;-)
<robclark> too bad srini doesn't seem to be on IRC atm
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]