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)
<HdkR> steev: Do you know where the BT firmware is found on the Windows side?
<HdkR> I see hpnv21.b8c is missing
<steev> yeah
<steev> scroll up a bit, i mention it
<steev> convo between bjorn and myself
<steev> but, it crashes a lot with the blsl shaders :(
<HdkR> Crash in minecraft is probably easier to debug than the crash in God of War that I'm trying to capture
<HdkR> steev: Also, only 14FPS?
<steev> yeah... i'm not sure what the settings are, but that server takes about 10gb of ram total to run once its going
<steev> or at least, it does on my windows machine
<steev> well, the client, connecting to that server
<steev> i'll be honest... i don't really know what i'm doing in minecraft and i pretty much just hang out in the spawn point on that server (it's a neuromancer/chatsubo themed server)
<HdkR> I'm just surprised the A690 doesn't crush it at 1200p
<HdkR> Hopefully the GPU clocks are full-speed?
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> that, i can't say
<HdkR> cat /sys/devices/platform/soc@0/3d00000.gpu/devfreq/3d00000.gpu/trans_stat
<HdkR> Gives you an asterisk next to the current clock speed
<steev> i'll check a bit later, need to report something in to work first
<steev> looks like... no?
<steev> or rather, it does bounce around
<steev> let me turn the BSL shaders back on
<HdkR> cat /sys/devices/platform/soc@0/3d00000.gpu/devfreq/3d00000.gpu/max_freq | sudo tee /sys/devices/platform/soc@0/3d00000.gpu/devfreq/3d00000.gpu/min_freq
<HdkR> Does that max it out? :P
<steev> at 69000000 it does sit at 50-60
<HdkR> Nice
<steev> that's with BSL shaders on too
<steev> just that yeah, every so often minecraft go boom
<HdkR> mesa_glthread=true environment variable probably necessary to make it stop sleeping so hard
<steev> fd_bo_heap_alloc+0x118
<steev> []
<steev> let me kick that variable on
<HdkR> Not quite the same fault that I'm getting
<steev> the dmesg output doesn't happen every time, but the fd_bo_heap_alloc does every time it crashes
<HdkR> Start of mine always end up being `gpu fault ring 0 ...`
<steev> is a crashlog from prismlauncher about it, i haven't read closer, but that's what happens every time it crashes :D
<HdkR> So likely just java crashing from the kernel recovering the hang
<HdkR> I saw Rob updated the a690 branch yesterday. Not sure if it will improve stability if you haven't pulled it yet
<steev> oh, i have not
<HdkR> A devcoredump might work on your case as well. Currently my crash doesn't give me an `ESTIMATED CRASH LOCATION` message
<HdkR> and of course I can't get a gfxreconstruct capture that can reproduce it.
<HdkR> Well I did find a nasty FEX crash while trying to find games that also reproduced. So that's good
<HdkR> Wow, Ender Lilies runs at 60hz 1200p with only 410Mhz clock. The 888 could barely run at 60hz at half res
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<HdkR> Oh, This keyboard has a bunch of ghosting problems doesn't it?
<HdkR> yep, checked with xev. Hopefully that's a kernel issue, not a hardware issue
<steev> i think clover reported similar?
<HdkR> I thought I just wasn't paying enough attention initially
<steev> the only time i notice an issue with it... i've fat palmed the touchpad and moved the cursor
<HdkR> Just needs someone to try and reproduce under Windows to see if the complaint needs to go towards Lenovo or Linux :P
<bamse> HdkR: do you know why my x13s says "libGL error: MESA-LOADER: failed to open msm: (null) (search paths , suffix _dri)" when i try to fex, with the ubuntu.ero i got from you?
<bamse> HdkR: is it trying to load mesa from within the ubuntu image or from my system?
<HdkR> From inside the ubuntu image
<HdkR> If you're setting mesa's loader override environment variables then that can introduce some weirdness
<bamse> thought i had unset that...let me double check
<HdkR> `FEXBash es2_info` is always a good test
<bamse>'s ""
<HdkR> lol
<HdkR> unset != set ""
<bamse> i know...
<bamse> guess i didn't know when i played with this last week though ;)
<HdkR> Thunks will punch GL/Vulkan through to your host drivers but it isn't super stable which is why it isn't the default.
<bamse> should i expect steam guard to say no?
<HdkR> I don't think so? But I don't know if I tried any games with it
<bamse> "LogonFailure No Connection"...
<HdkR> Oh, the login thing
<bamse> yeah
<HdkR> I think if you retry a few times it works. I've noticed it does this even without emulation
<HdkR> Or restart it can make it pick up the connection?
<bamse> yes, it did this 2-3 times for me on my PC earlier today as well...
<bamse> just wanted to cehck if i should continue to try :)
<HdkR> It's a weird one. Steam bug as far as I'm aware
<HdkR> There's a weird bug with the Steam Guard QR code sign in that only appears under FEX though. It'll time out after ~5 seconds and you need to race it to scan
<HdkR> Without emulation it never times out, and self-updates after every 60 seconds
<HdkR> ¯\_(ツ)_/¯
<bamse> seems like hitting refresh a few times on the qr code makes the duration longer :)
<bamse> time to get some sleep, maybe steam guard likes me better in the morning
<HdkR> I'll say it's Google's fault because of Chromium :P
<steev> speaking of emulated games... how does fex handle dwarf fortress?
<HdkR> I don't think I've tried it
<steev> like bjorn, i think it's time for sleep here, i really dislike my 9am meeting
<bamse> if only i went 10 minutes ago...
<bamse> the school bus arrives in 7h20m...
<HdkR> Hm, definitely have some work to do so load time is improved
<HdkR> Causing a bunch of code to be JIT
<HdkR> Double check that GL thunks work
<HdkR> Seems fine past the initial load
<travmurav[m]> HdkR: Dwarf Fortress?
<HdkR> Yea
<travmurav[m]> Huh, is this classic or the steam release?
<HdkR> Steam Release
* travmurav[m] wonders how many simulation frames it gives on embark
<HdkR> I don't even know what that means. I don't play the game :)
<travmurav[m]> I was afraid to even try it on 7c given the game is mostly cpu
<travmurav[m]> you can enable "fps counter" in settings and the lower number would be simulation ticks :D
* travmurav[m] wonders if fex could handle classic + something like dftherapist that basically attaches a debugger to the game process
<HdkR> If it uses ptrace then no
<travmurav[m]> Actually I suppose proton shouldn't have much overhead even, given it's just the library calls?
<HdkR> Compared to the fact that we're emulating the world, it's quite low overhead
<travmurav[m]> Cool, ngl I was very impressed with fex when I tried it on the 7c a week or so ago, even though I couldn't really get into anything playable given the low perf hw
<HdkR> 7c is a bit rough, especially since you're likely to swap with every game
<travmurav[m]> Yeah I had to add 8gb zram to even get anywhere
<travmurav[m]> (4gb ram device)
<HdkR> Quite painful
xroumegue has quit [Ping timeout: 480 seconds]
<travmurav[m]> Well, given my expectations of "won't even run" I was quite impressed to see full steam ui and even 3-10 fps in Antichamber, which was the only game I ended up getting to not crash on start
<HdkR> 32-bit game so thunks won't even work on that one right now
<HdkR> And 60% of games on Steam are Unity which are a bit flaky atm
xroumegue has joined #aarch64-laptops
<HdkR> Antichamber taking quite a while to load because of this slow USB perf
<szclsya[m]> phew, finally have time to do some x13s work
<szclsya[m]> has been updated
<travmurav[m]> HdkR: Oh, I think I left it opening and went away for half a hour with no expectations and was genuinely surprised that it was not a black screen when I got back
<HdkR> travmurav[m]: Looks like about 14FPS in the loading room area
<travmurav[m]> For me it was like 10 and it drops heavily in some places not far away from the start
<HdkR> Completely single core bounded, likely because of 32-bit issues
<travmurav[m]> that is, as soon as the environment gets dynamic...
<travmurav[m]> but I suppose it's hit by emulating the whole mesa...
<HdkR> Indeed, cutting out libGL in 32-bit applications will be a big win
<HdkR> Oh, this game also uses PhysX, which I know is quite heavy on CPU
<HdkR> travmurav[m]: 40 FPS if I enable mesa_glthread and relaxed x87 precision
<HdkR> First level back to 17. Womp womp
<HdkR> Kind of all over the place
<travmurav[m]> Oh I completely forgot mesa can multithread... Yet I guess 7c won't have much chance without 32bit hunks anyway
GuildedThorn has joined #aarch64-laptops
<HdkR> I'm also looking forward to 32-bit thunks :P
maz_ has quit [Ping timeout: 480 seconds]
maz has joined #aarch64-laptops
indy has quit [Ping timeout: 480 seconds]
<amstan> here come the thunks again!
<amstan> so what's a thunk?
<HdkR> amstan: A library that jumps between x86/x86-64 architecture and aarch64
<HdkR> So an x86 application will call glDraw, and that glDraw that lives in the thunked libGL shim will marshal the function arguments over to the aarch64 libGL's glDraw function
<HdkR> Which lives in the same address space
indy has joined #aarch64-laptops
miracolix has quit [Remote host closed the connection]
<amstan> cool
<HdkR> Crossing the 32-bit x86 -> AArch64 threshold is the hard bit
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit []
jhovold has quit [Quit: WeeChat 3.7.1]
iivanov has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
iivanov has joined #aarch64-laptops
svarbanov__ has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
svarbanov__ has quit [Read error: Connection reset by peer]
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
iivanov has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
GuildedThorn has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
echanude has joined #aarch64-laptops
init has joined #aarch64-laptops
<init> I've been unable to play with the X13s and linux for a good while. I've tracked the patch coming in linux-next a bit. is there a wiki somewhere with support status on 6.2 or next? Specifically looking to see if there's a timeline on gpu, and if it will now boot vanilla (6.2) with a good config, or if we still need a special fork. Thanks.
<bamse> init: still a few missing pieces to have mainline just boot, but v6.3 is going to be close
<bamse> init: but there's still a bunch of things in the v6.4 will be much better...
<szclsya[m]> is the Mesa patch merged upstream yet? if no you'll also need a patched version of mesa
<bamse> init: and gpu is working, but patches are not landed yet
<init> nice, i might start running it full time then and live with the changes
<init> is jhovold fork still the most up to date?
<danielt> Leo Shen: w.r.t. x13s-alarm... I think the advice at the bottom of the readme about efi=novamap is out of date.
<danielt> (I didn't use it... I just reviewed things since the mesa was known working ;-) ).
<bamse> HdkR: gave up on typing in the steam guard code and used the qr-code-based login...that finally worked
<bamse> HdkR: so, given the number of times i tried...i don't think the typing-in-guard-code-method works
<jhovold> init: yes, steev's branch is based on that one and also has some bluetooth patches which I have not yet had time to test and review
<jhovold> init: if you build your own mesa and find the right fw, my 6.2 branch should give you gpu and audio
<init> great. jhovold, when you say the right fw, are you refering to the fact that in the patches, it was using a different but similar gpu firmware file?
<jhovold> it's just that the gmu fw has not been released yet, qzed has extracted one that we can use meanwhile
<szclsya[m]> danielt: oh nice, one less quirk! I'll try it out and remove that line
<jhovold> similar for audio, you need a bunch of files from srinik's repos
<init> interesting
<jhovold> for gpu, the fw should otherwise be in linux-firmware now
<szclsya[m]> yeah that one's working
<steev> yeah, at this point, there's very little in my tree that isn't already in jhovold's
<steev> just a different broader (based on debian) defconfig mainly, whereas johan's defconfig is better for working on development and faster build times
<init> a690_gmu.bin does not seem to be in any linux-firmware branch tho
<steev> it is in the linux-surface firmware repo
<szclsya[m]> you may also want firmware/qca/hpbtfw21.tlv in aarch64-firmware to make bluetooth work
<szclsya[m]> doesn't seem to be in linux-firmware too
<steev> it should be in upstream firmware
<szclsya[m]> hmm maybe my firmware is out of date
<steev> the nvm patches aren't in upstream linux-firmware, and we probably need to poke lenovo about getting them to submit them; but there are definitely questiosn there
<szclsya[m]> oh yeah you're right
<szclsya[m]> any update on the wireless front?
<steev> the nvm patches aren't strictly required, but if you want em, you can grab them off the windows partition, the latest firmware update should have them in a folder called qcbtfmuart_hsp8280.inf_arm64_69bd85311531b34a
<steev> sadly, no, we're still waiting there
<steev> just note that the windows firmware calls it *.bXX and on linux, assuming i've pushed out the latest (and i probably haven't), it'll be looking for *.XX
<steev> i should do that since 6.2.1 is out now
<szclsya[m]> huh the wifi chip is also on a snapdragon 8gen1, interesting
<szclsya[m]> I thought 8cx gen3's board design is more similar to 865
<steev> the wcn6855/qca2066/hsp8280 (seriously... can they make up their damn minds) been around a while
<szclsya[m]> oh wait I have one on my x86 thinkpad lol
<szclsya[m]> 01:00.0 Network controller: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter (rev 01)
<szclsya[m]> turns out to be a wcn6855 under the hood
<clover[m]> do you have one of those z thinkpads with the amd chips Leo?
<szclsya[m]> yup, z13
<szclsya[m]> soldered wifi but fortunately it's a pretty good one
<clover[m]> how is it with linux?
<szclsya[m]> it's perfect afaik
<clover[m]> does the webcam work?
<szclsya[m]> it works out of the box
<szclsya[m]> (it's just a usb webcam, nothing special
<steev> I’d say it’s a shame the x13s isn’t, but I like knowing it doesn’t work
falk689 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
<steev> qzed: do you have a version of the uefisec stuff that takes into account the include/linux/qcom_scm.h to include/linux/firmware/qcom ? for some reason it keeps telling me that the second hunk of the patch is already applied despite very clearly not being applied
<steev> sorry, not second hunk, second file - it tells me that the drivers/firmware/qcom_scm.h file has its bits applied when they clearly aren't
<qzed> I assume that's on some -next branch? I haven't worked on that lately, but I guess I can try to get one working in a bit
<steev> it's in torvalds now
<qzed> I think the latest I have is 6.2 and some next from late january... give me a couple minutes to try sort out my dotfile mess and I'll get on it
<steev> no worries at all
<steev> it should be in -next as well
janrinze has quit [Quit: Leaving.]
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> steev: thanks a lot for the hint about the debian packaged qcom tools - will have a look
<steev> :)
<steev> should be: protection-domain-mapper qrtr-tools rmtfs and tqftpserv
<hexdump0815> jenneron[m]: it looks like this ec with many i2c connections seems to be the case for many samsung devices - the samsung galaxy book go seems to have something at least very similar as well according to the acpi dsl
<hexdump0815> steev: looks like all one can wish for :)
<steev> but yeah, looks like they're just in unstable and testing for now; bookworm *should* get it
<hexdump0815> thats fine as bookworm should be final in a few months
<steev> si
<qzed> only compile-tested though
<steev> sounds good :)
hightower2 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<steev> modifying the patch set from jhovold to use the correct compatible for the new version does seem to work here
<steev> robclark: with your patchset.. the cursor acts extremely laggy under Xorg
<steev> it's fine under wayland, but if we wanna do external display on the thinkpad currently with gnome, we're limited to xorg
<robclark> steev: does dropping `drm/msm/atomic: Switch to vblank_start helper` change things? If so maybe the timing info for your display isn't right?
<steev> will give it a shot - it's possible mine is wrong, we're using the generic one since (afaik) no one has the datasheet
<robclark> I guess you should be getting an EDID from the panel? Anyways, I guess later I can hack up something to print out the vblank start times calculated the old vs new way and give you a patch to spam your dmesg
<steev> robclark: :/ yeah reverting that patch does seem to get rid of the lag
echanude has quit [Ping timeout: 480 seconds]
<steev> and yeah, we do get an edid
<robclark> I'm not _entirely_ sure what could be wrong in the EDID resulting in a good picture but incorrect calculation of start of vblank..