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?
<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
<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>
https://mclo.gs/joVKOEq 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>
LIBGL_DRIVERS_PATH probably
<HdkR>
`FEXBash es2_info` is always a good test
<bamse>
ugh...it'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
<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
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 air...so 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>
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]>
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
<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