robclark 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
svarbanov has quit [Ping timeout: 480 seconds]
possiblemeatball has quit [Ping timeout: 480 seconds]
<steev>
yeah we still have a few things "always on" that shouldn't always be on
<rfs613>
yep. Under linux, if I "suspend", it drains battery more quickly than windows. So something(s) are not fully powered down.
<rfs613>
for example if you "forget" about the laptop for a day or two, the battery under linux will be drained.
<steev>
we will get there, i hope. the c630 gets like, 5 days suspend/closed but powered on
<adamcstephens>
I feel like 6.9 is slightly better on suspend drain on the x13s
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
KREYREN_oftc has joined #aarch64-laptops
<steev>
could be, there are definitely improvements with each kernel release... just regressions in other parts :(
jglathe_x13s has joined #aarch64-laptops
<bumble[m]>
it all sounds really good to me :) the only downside seems to be, reviewers who resonate well all say they do not like the keyboard and some really hate the keyboard
<steev>
when i'm using it mobile, i have no issues
<bumble[m]>
thanks, okay no other concerns from me :)
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest2198
ungeskriptet has joined #aarch64-laptops
Guest2198 has quit [Ping timeout: 480 seconds]
* gwolf
agrees with steev's experience
<gwolf>
suspend _does_ drain somewhat more than what I'd like. But it is bearable...
<steev>
i'm tempted to do that command thingie from windows, just in case, but... i never boot into windows so no idea if that affects anything
<steev>
worst case, it still does nothing, i suppose
jhovold has joined #aarch64-laptops
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
<jglathe_x13s>
Hmm @rfs613 I took a look on powercfg in Windows. Nice. powercfg /a shows what's actually supported (from Windows POV). Did the powercfg hibernate off (it was on), we'll see.
<jglathe_x13s>
Thank you
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
indy_ is now known as indy
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
<albsen[m]>
strange, I got another x13s (from ebay) and the bios isn't showing the config->linux option anymore. lenovo update doesn't show the bios update as installable but on the website its available to download for the machine. its version 1.60, is this update save to run?
<albsen[m]>
ok, it came with 1.48 - needs to be on 1.49. if its save to upgrade the bios to 1.60 - not sure. I'll upgrade to 1.49 as this adds linux support. let me know if anyone is running 1.60 without issues pls.
<abby>
I'm on 1.60 iirc
<abby>
works fine
<jglathe_x13s>
1.60 here, works well. Even tested the "Linux" option, loaded the dtb from EFI partition.
<albsen[m]>
got burned by lenovos bios updates too many times in the past
<albsen[m]>
also research before upgrading :)
<albsen[m]>
always ... not also
<albsen[m]>
anyway, thx
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
<jhovold>
albsen[m]: you can run linux just fine also on older uefi fw without the "linux mode" option, or when the option is disabled
<jhovold>
you just need to load the dtb using grub instead of relying on the fw to do it for you
<jhovold>
and make sure to pass efi=noruntime, that's it
<jhovold>
that said, there may be other reasons for wanting to run a later version of course
<albsen[m]>
jhovold: wasn't sure if that works. the other model I have came with 1.49 so I never had a reason to upgrade
<exeat>
albsen[m]: Lenovo fixed some very annoying keyboard problems in 1.56 and 1.57
<exeat>
(Also on 1.60 here, no problems)
KREYREN_oftc has quit [Remote host closed the connection]
<HdkR>
The keyboard ghosting problem was a nightmare
<rfs613>
jglathe_x13s: glad it was useful. I would not expect powercfg to have any effect on linux. But it on windows, it fixed the inconsistent sleep behaviour - now it sleeps when ii close the lid, and battery drain in that state is minimal (maybe 1 or 2% overnight).
<rfs613>
exeat: yeah that keyboard issue was bothering some people. I can't say I ever noticed it myself. EIther I type too slowly, or I was just not affected.
<HdkR>
exeat: Yea, n-key rollover issue. If you're typing quickly you would hit the issue. I still use an external keyboard attached to the laptop because of it :D
<exeat>
It wasn't very severe for me, but the x13s kb never felt quite right (more missed keystrokes than I could blame myself for) until that 1.5x fix
<HdkR>
Some devices for some reason didn't hit it, which I can only think there was some minor keyboard SKU differences
<HdkR>
We tested something like half a dozen and I think only two hit it?
svarbanov has joined #aarch64-laptops
<exeat>
The only remaining kb blemish is that I can't do a leftshift+win+right. I think someone here said that it's a hw limitation.
<rfs613>
HdkR: my undestanding is the keyboard issue was due to fast polling of another i2c device (keyboard is hid-over-i2c). Might be related to wwan modem, which mine doesn't have.
f_ has quit [Ping timeout: 480 seconds]
<HdkR>
rfs613: None of mine have wwan either
<HdkR>
Interesting idea although
<rfs613>
HdkR: it's all based on speculation on lenovo forums and elsewhere... no idea if any of it is true
<HdkR>
At least it is fixed now, so we don't need to care :)
<rfs613>
indeed
hightower2 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest2218
ungeskriptet has joined #aarch64-laptops
Guest2218 has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
<jhovold>
rfs613: was there some explanation about what that powercfg command does?
<jhovold>
I think bamse measured the windows suspend (to idle) power consumption to be roughly the same as what we have under Linux currently
<jglathe_x13s>
what is Persisted_Capsules.bin btw, written today...? I have the efivar patches, 6.9rc5
<jhovold>
But if Windows implements hibernation, as I would assume, then enabling that during "suspend" should give you much better "suspend" power consumption of course
<rfs613>
jhovold: AFAIK the command disables hibernation... it should not affect sleep.
<jhovold>
so disabling hibernation improves suspend to idle consumption for some reason?
<jglathe_x13s>
you can also enable it with this. It shows what s possible (and what not, even with explanation)
<rfs613>
but the issue I was seeing in windows, was that you close the lid, and it sleeps... for some random duration (a few hours typically)... and then it goes into some lower power (maybe hibernate) mode.
<jhovold>
right, that's the behaviour I would expect
<jglathe_x13s>
like "hypervisor doesn't implement somefeature therefore nope"
<rfs613>
when it does that, wakup takes longer (you see bios splash screen) etc
<jhovold>
that should be hibernation then
<rfs613>
it was annoying because it was unpredicable when it would kick in... there was no pattern, not related to battery level, or how long it was sleeping before it hibernates, etc
<jhovold>
and now, do you always see the splash screen when opening the lid?
<rfs613>
so sometimes you'd open the lid and it would be instant on, other times it was 30 seconds
<rfs613>
now I never see the spash screen, it is always instant-on
<jhovold>
ok, and lower suspend power consumption too?
<rfs613>
and the battery drain while sleep is quite minimal
<rfs613>
i've not measured scientifically, but overnight it's maybe 1 or 2 %
<jhovold>
interesting, thanks for the details
<rfs613>
previously (wiht the hibernate support) it seemed to be worse for some reason..
<rfs613>
jhovold: with your 6.9-rc4 when I close the lid, the screen turns off, and I guess the CPU suspends (or at least network drops, I cannot SSH into it anymore).. but the battery level drops perhaps 1% per hour
<rfs613>
i did not spend a lot of effort trying to debug the linux power usage, this is just an observation
<jhovold>
right, we're not in the deepest low-power mode, I measured around 30h a few months ago
<jhovold>
it's a known limitation/issue
<rfs613>
30h seems about right, I was estimating somewhere between 1 - 2 days
<jhovold>
so you can suspend over night, or on the way home from work, but should remember to plug in the charger after that
<rfs613>
exactly... i'm plugged in most of the time, but occasionally (esp on weekends) I move the laptop out of the way...
<jhovold>
depending on current battery level of course...
<rfs613>
and in that case if I forget to shut it down, it will probably be dead on Monday morning
<rfs613>
whereas on Windows (with hibernate off) it will be pretty much exctly where I left it, battery-wise
<rfs613>
anyhow its WBN but certainly not a dealbreaker... the other improvements to graphics, sound, etc are very welcomed.
<jhovold>
yeah, we should be able to get there at some point too hopefully
<jhovold>
adamcstephens (and craftyguy): when you say pipewire works, does that include capture?
<jhovold>
I could get playback to work by capping the max quantum size to 1024 as exeat had discovered, but also with that any recording sounded was still choppy
<jhovold>
I think steev referred to is as "robot with hiccups" or something
<jhovold>
I'm pretty sure I tested 2048 quanta at the time too but that did not help then
<rfs613>
FWIW for audio, I only tested playback, with whatever is default quanta... noticed occasional hiccup but mostly fine.
<jhovold>
what distro is that?
<rfs613>
debian 13 with your 6.9-rc4 kernel
<jhovold>
I think srini uses debian too, perhaps some default distro settings that improve things?
<jhovold>
could you try recording use parecord?
<rfs613>
let me see...
<jhovold>
when I tried pipewire, I think I even the volume meters in pavucontrol showed the issue by never going down to 0
<jhovold>
as if also silence was "choppy"...
<rfs613>
parecord is raspy / not clean
<jhovold>
thanks for confirming, was that the digital mics?
<jhovold>
or headset jack?
<rfs613>
the built-in mics
<jhovold>
was what I tested with too
<jhovold>
works fine with pulseaudio...
<rfs613>
to me it sounds like clipping
<jhovold>
perhaps a different issue then, do you have the latest ucm files?
<jhovold>
1.2.11
<rfs613>
yeah i installed the dependencies as per your wiki page
<rfs613>
but debian version of linux-firmware isn't quite as new as the one you listed
<jhovold>
might be worth checking if switching to PA makes the problen go away
<rfs613>
i'm using 20230625-2 from debian trixie
<jhovold>
may be an issue too, I think linux-firmware-20230919 was the needed beacuse of some audio changes
<jhovold>
a symlink and one more late change
<rfs613>
maybe i'll try later, right now have some other stuff to take care of
<jhovold>
sounds good, thanks
<jhovold>
I should try to find some time to test pipewire again too, just too many things going on at once as always...
<adamcstephens>
jhovold: i just tried capture on pipewire and it sounds awful
<adamcstephens>
luckily not something i normally need on this laptop
<jhovold>
adamcstephens: thanks for confirming
alfredo has joined #aarch64-laptops
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
possiblemeatball has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<\[m]>
yes latest kernel always freezes when I come from suspend
<\[m]>
with the usb hub (I stopped using the lenovo dock for a simpler alternative since it wasn't providing better stability anyway)
<jhovold>
\[m]: as i've mentioned before the drm driver hotplug implementation is known to be broken
<\[m]>
reporting because it was more stable before
<jhovold>
but you should be able to suspend and resume as long as you keep the external display connected
<\[m]>
oh so it s pebcac as usual 😄
<jhovold>
and keep in mind that it's not just whether the display is physically connected that matters currently, also whether the display is on or not
<\[m]>
so tldr, just shutdown instead of suspend and life is good 🙂
<\[m]>
I was disconnecting the cable of the dock now before closing the laptop
<jhovold>
well before 6.9 you had to disconnect before suspending, not easy to keep up ;)
<\[m]>
and then reconnect it after login
<jhovold>
that should work with wayland, but breaks with X here, maybe depends on the VM too
<rfs613>
my solution is two laptops, rather than an external display
<rfs613>
i never tried with the x13s, but on my x1 carbon, connecting an external monitor caused noticable heat on the left side of the keyboard.
<rfs613>
the heat is annoying, and moreso when it causes the fans to spin up
<rfs613>
without the external display, both machines are totally silent, except when a web browser tab goes crazy ;-)
<rfs613>
the x1 carbone lets me know by its fans, while the x13s just gets warm after a while ;-)
<Jasper[m]>
What dock are you connecting through?
<\[m]>
powerexpand 7in1 something basic cheap
<Jasper[m]>
Ah anket, alright
<Jasper[m]>
*anker
<bamse>
jhovold: i never managed to conclude what windows would do in this case...modern standby does indeed disable hibernation, but my windows laptop does indeed hibernate in some form when on battery...so i think my testing was incomplete...
<\[m]>
jhovold I'm on wayland, the behavior seems to only be in your latest wip
<rfs613>
Jasper[m]: i'm using one from j5create, which was recommended to me loong ago for the c630
<\[m]>
I run now again rc2 will know tomorrow
<jhovold>
\[m]: there shouldn't be anything that I changed in rc5 that would cause a suspend regression, but maybe something changed in mainline
<jhovold>
suspend still working fine here
<jhovold>
is it failing every time you suspend?
<jhovold>
and only after disconnecting an external display?
<bamse>
jhovold: my mouse cursor is gone today btw...
<jhovold>
yeah, I ran into this when moving to wayland too
<bamse>
jhovold: and i only updated the kernel package
<bamse>
it was there when i started sway, but now after the screen has been turned off it's gone
<jhovold>
appears to be another bug in the drm driver but havn't had time too narrow it down and report it
<bamse>
okay, just figured i'll mention it
<bamse>
but if so, i'll mention it to dmitry as well
<\[m]>
it's on reconnect, my process now is, disconnect before resume, then reconnect when I re login
<jhovold>
sway falls back to software cursor after a power cycle
<jhovold>
likely related to the hotplug mess
<jhovold>
power cycle of the monitor that is
<jhovold>
but that fallback doesn't work with my new compositor so I end up with no cursor at all
<jhovold>
\[m]: and the machine crashes when you reconnect the display after suspend?
<jhovold>
bamse: which kernel did you update from? and to rc5 i assume?
ungeskriptet has quit [Ping timeout: 480 seconds]
f_ has joined #aarch64-laptops
possiblemeatball has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
Aldric has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
<\[m]>
<jhovold> "\: and the machine crashes..." <- freezes the main screen, or both, once I kept replugging and indeed it force rebooted/crashed
<\[m]>
s/resume/suspend/
<\[m]>
oh I fcked up, it's disconnect before suspend, and reconnect after logged in
<\[m]>
before it would freeze the main screen, but I could go into display settings and disable / enable internal screen though last 2 times it actually froze the system too then
alfredo has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
<craftyguy>
jhovold: FYI capture is still messed up with pipewire (tested with parecord)
<\[m]>
why not use pulseaudio just for now?
hightower3 has joined #aarch64-laptops
<craftyguy>
from what I understand, PA is basically on life support
<craftyguy>
I think many distros ship PW by default now? (we want to in postmarketOS at some point, soon hopefully)
f_ has quit [Remote host closed the connection]
f_ has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
possiblemeatball has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
rz_ has joined #aarch64-laptops
rz has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
xeld[m] has joined #aarch64-laptops
jglathe_volterra has joined #aarch64-laptops
<steev>
jhovold: if you're still taking changes for defconfig; binftm_misc please, so i can run amd64/i386 binaries
<steev>
binfmt_misc *
<bamse>
jhovold: i was on v6.9-rc1, didn't see the problem...now i'm on v6.9-rc5
f_ has quit [Ping timeout: 480 seconds]
svarbanov has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
<bumble[m]>
just in the last few hours amazon sold out of their refurbished x13s... I wish I had bought one
<bumble[m]>
I was going to buy today but too late
<craftyguy>
is ebay an option for you? I haven't looked recently, but there were some there (on US ebay at least) a few weeks ago
<steev>
ah dang, i was too bumble[m] :(
<HdkR>
steev: fusefs is a good option as well if not already enabled :P
<steev>
HdkR: i don't use that, so idk about it:)
<steev>
but it does look like it defaults to M
<bumble[m]>
ebay is an option but the deals there now are not as good as the now-sold-out amazon stock
<bumble[m]>
on reddit I found a discussion thread where someone who supposedly works with lenovo said the x13s won't be continued
<bumble[m]>
which makes me want one all the more :)
<steev>
yeah, it's gonna be... T14s? for the x1~~google~~elite version, i guess?
<bumble[m]>
perhaps it will be the last fanless ARM variant as well. manufacturers will probably pretend there is no consumer interest in such things and everyone needs more power and more fans
<steev>
that would make me sad... since, afaik, apple doesn't have fans on their m3 variant
<HdkR>
Macbook Air M3 is fanless, Macbook Pro M3 still has a fan
<HdkR>
Macbook Pro M3 Pro/Max gains an additional fan
<steev>
yeah, i mean air
<HdkR>
23W TDP is pretty spicy for fanless designs but not impossible
<HdkR>
80W TDP config, definitely won't be in a fanless design :D
<steev>
clover[m]: just pushed out 6.8 with the in-kernel pd-mapper patcheset (and the 1 needed fix from next); you need to enable QCOM_PD_MAPPER to use it (and disable the userland service)
<clover[m]>
Ok steev thanks. I will give it a try when I get some free time. Do you reckon laptop defconfig is still borked?
<clover[m]>
For me that is...
<steev>
considering i have no idea what broke on your end... yes :(
<steev>
throw me a working 6.7 config, and i will try to take a look tonight
<robclark>
HdkR: but those are "system tdp" rather than package tdp... so tbh I'm not entirely sure how to compare them (which I suppose was the point)
<HdkR>
robclark: True
<robclark>
I guess 23w system tdp is something like 15w tdp??