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
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
agl has quit [Ping timeout: 480 seconds]
ektor52 has joined #aarch64-laptops
ektor5 has quit [Ping timeout: 480 seconds]
agl has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe has quit [Ping timeout: 480 seconds]
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
hexdump0815 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
hexdump02 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
fantom has quit [Ping timeout: 480 seconds]
<osmoz[m]>
Thanks a lot, so I will need to look for carefully for which firmware are needed to boot
ksco has joined #aarch64-laptops
ksco has quit [Remote host closed the connection]
fantom has joined #aarch64-laptops
ksco has joined #aarch64-laptops
ksco has quit [Remote host closed the connection]
fantom has quit [Ping timeout: 480 seconds]
ksco has joined #aarch64-laptops
<ksco>
jdb: yes IVO R133NW4K-R0 (0x854b) is the one known to work without issues, touch or non-touch seem does not matter, thanks for checking on you side.
<ksco>
anyway, I decided not to dwell on this and am trying to buy another one with the right screen. wish me good luck! ;)
fantom has joined #aarch64-laptops
ksco has quit [Quit: Page closed]
chrisl has joined #aarch64-laptops
eluks has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
sally has quit [Quit: ZNC 1.9.1+deb2+b2 - https://znc.in]
sally has joined #aarch64-laptops
sally has quit []
sally has joined #aarch64-laptops
Grabunhold_ has quit [Ping timeout: 480 seconds]
Grabunhold has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
valpackett has quit [Read error: Connection reset by peer]
valpackett has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
pbrobinson has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
pbrobinson has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe_ is now known as tobhe
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
etehtsea has quit [Read error: Connection reset by peer]
etehtsea has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
krei-se has joined #aarch64-laptops
pbrobinson has joined #aarch64-laptops
pbrobinson has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
whiskey9 has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<dgilmore>
robclark: what kind of move? I guess I missed something somewhere
<Jasper[m]>
To qcom I think?
<Jasper[m]>
From Google/Cros
<dgilmore>
ahh cool
<dgilmore>
congrats robclark
pbrobinson has joined #aarch64-laptops
<robclark>
dgilmore: thanks, yeah now I'm working from the "inside" :-)
<valpackett>
yea and the issue was it not loading at all
<valpackett>
congrats robclark! looks like qcom is going bigger and bigger on upstream \o/
<robclark>
:-)
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
has someone an ideapad 14q8x9? Looking for the DSDT
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
eluks has joined #aarch64-laptops
<erebion>
My X13s recently started taking a really long time to wake up from suspend, has anything changed in the kernel that could cause this? Am currently on 6.12.27
<alexVinarskis[m]>
Running next-20250605 which was still broken for me. Reverting this commit fixes the issue, it wakes up with no SSD errors. Valpackett: could you cross-test to confirm the findinds?
<agl>
erebion: What kernel do you use. "steev" generates the newest kernels for the x13s. You find his kernels at https://github.com/steev/linux/
<agl>
Try it i mean this is one patch that the x13s runs quickly.
<erebion>
> erebion: What kernel do you use. "steev" generates the newest kernels for the x13s. You find his kernels at https://github.com/steev/linux/
<erebion>
Whatever Debian has. I just use that and am glad it works. :)
<agl>
erebion: I us Debian13/trixie with the kernel from steev (you must compile it by yourself) and all works fine.
<erebion>
Neat. Then I'll probably get the changes at some point anyway. ^_^
<agl>
erebion: steev uses the newest kernel and makes the patches especially for the x13s.
<agl>
erebion: Use the branch "lenovo-x13s-linux-6.14.y".
<agl>
erebion: The aktual kernel is 6.14.9
<valpackett>
alexVinarskis[m]: interesting!! will check soon
<konradybcio>
alexVinarskis: always nice to see it's not me in Author:
<konradybcio>
any chance that depth-- can underflow?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<alexVinarskis[m]>
Hmmm perhaps. Unfortunately I won't have time to debug this until Saturday... thinking that it probably makes sense to report it back to original author once valpackett confirms it solves same issue on their side as well, and let them decide if they would like to revert it/fast fix it/leave it as is (and thus break upcoming 6.16-rc1)
<steev>
erebion: i don't *think* anything in 6.12 would have that affect (also fwiw, i also patch the 6.12 kernel since it is long term - plus trixie will have 6.12 on release
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
speaking of which, new kernels dropped today
<steev>
it's family dinner day though so dunno if i'll get around to building and testing them
<bamse>
agl: better to use the distro kernels, in particular on x13s...and if it doesn't work we should fix that
chrisl has joined #aarch64-laptops
<steev>
bamse: with your qcrypto change, the distro kernel doesn't work - i keep meaning to reply to the email
<bamse>
it's fine to use steev's kernel to help test the patches that steev is carrying, but upstream (and hence distro) should just work
<bamse>
steev: which patch is that?
<steev>
i think it's `# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set` the one that adds the crypto nodes in for sc8280xp
<bamse>
didn't think we merged crypto into sc8280xp.dtsi...
<steev>
its the same thing we saw on the c630 and i ended up sending a patch to disable on the c630
<steev>
we haven't, but i was testing it before it merged in
<bamse>
ohh, yeah but then the distro kernel can't be broken...
<bamse>
okay, so without DISABLE_TESTS it will test the qcrypto support?
<steev>
apparently so
<steev>
and the x13s does the same thing as c630, as soon as it tries to test whatever it tests... boom
<bamse>
good, i never pushed the patch because i couldn't figure out how to test it
<steev>
and my c630 it looks like is... deadge
<steev>
it powers on but never gets to bios
<bamse>
hmm, there's no CRYPTO_MANAGER_DISABLE_TESTS in upstream kernel(?)
<steev>
in 6.16 it becomes CRYPTO_SELFTESTS it looks like
<steev>
but i gotta say
<steev>
the commit message is confusing as fuck
<steev>
Replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS which has the expected behavior.
<steev>
The tests continue to be disabled by default.
<steev>
HOWEVER, everything is setting CRYPTO_SELFTESTS==y ?
<bamse>
hehe, magical...but that's good, i should go take a look at that
<bamse>
in other news, is it expected that if i load linux-nexst on my xps13 i have 100% load dancing around on one core all the time?
<bamse>
seems attributed to whatever processes happened to running...so perhaps some tasklet/softirq work?
<bamse>
hmm, or it might just be networkmanager
mbuhl has quit [Remote host closed the connection]
mbuhl has joined #aarch64-laptops
Caterpillar has quit [Quit: Konversation terminated!]
<steev>
someone else... valpackett maybe? was seeing that as well
<steev>
but no, networkmanager should not be using 100% cpu
<steev>
i wonder if it's trying to do something or read something (remember the weird ath11k issue with the sc8180x with thermal? it would kick in the cpu til it eventually timed out)
<bamse>
that sc8180x bug was just hanging for a second per read...so that would reflect a 0% load
<bamse>
but indeed nmcli d wifi disconnect wlP... drops the load to 0% again
chrisl has joined #aarch64-laptops
<bamse>
still idling at 46C...but at least the fan isn't going...