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
<dgilmore>
steev: 4, 5, and 6
<steev>
dgilmore: what 6.xx?
<dgilmore>
6.8.0
<dgilmore>
Fedora 40 has 6.7.2, 41 and rawhide have 6.8.0
<dgilmore>
steev: looking for something in particular?
<abby>
fedora still has qt4?
<steev>
dgilmore: if wireshark crashes with 6.7.2 on f40
<steev>
wireshark -> ctrl+o
<steev>
ideally if it does on 6.8.0 as well
<abby>
works fine with 6.7.2 on void
<steev>
abby: you can open files?
<abby>
yep
<steev>
i'm assuming arm64
<abby>
oh, i can check on arm
<steev>
yeah it's specifically on arm645
<dgilmore>
I don't have F40 installed anymore, but can spin up a VM.
<steev>
basically in debian, as soon as you try to open a file, it segfaults
<abby>
is there a stderr log?
<abby>
it *might* be something using private qt symbols
<dgilmore>
Is the qt frontend in the upstream Wireshark? Last I know we had disabled the frontend because it was gtk2
<abby>
yes
dlg has quit [Remote host closed the connection]
dlg_ has joined #aarch64-laptops
<steev>
yeah, afaik, they only do qt now
<kuruczgy[m]>
robclark: re drm native context, I am seeing the guest kernel identifying cap set id 6, so I guess that's good. But vulkaninfo is not seeing it. Which mesa driver is needed in the guest, virtio or freedreno? Do I need to enable any specific mesa compile option?
chrisl has joined #aarch64-laptops
dlg_ is now known as dlg
<robclark>
you need freedreno but maybe virtgpu kmd isn't enabled by default in distro configs
<kuruczgy[m]>
robclark: Any idea about the above error? How would I go about debugging it?
<kuruczgy[m]>
(Also maybe at this point this is getting a bit off-topic for this channel, is there another channel where this discussion would be more appropriate?)
<kuruczgy>
(It seems that I cannot send in #freedreno, some issue with NickServ, will figure that out later.)
<robclark>
fwiw digitex is also in #freedreno ... he should be more aware of the current state of qemu.. as far as guest kernel, I think everything needed should be landed
<robclark>
oh, you probably need to be authenticated with NickServ to speak/send
<robclark>
I guess I can drop that restriction and hopefully spam won't come back
<kuruczgy>
Okay, thanks. I need to go to sleep soon, so I will continue with this tomorrow. I will join #freedreno (with or without NicServ), and describe the issue again there.
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
sg
krei-se- has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
eac12 has quit [Quit: bye]
chrisl has quit [Ping timeout: 480 seconds]
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
eac12 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
echanude has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<jhovold>
rsalveti, anonymix007[m], maz, tobhe_: I've just reported my findings regarding the buggy t14s uefi fw and included the workaround that allows me to boot kernels here:
<davidinux>
tobhe_: I think you're stil missing this though for sound to work properly b4 shazam 20241023124152.130706-1-krzysztof.kozlowski@linaro.org
<jhovold>
steveej[m]: don't do that then ;) I have a vague recollection of someone trying that and it resulting in such errors
<steveej[m]>
jhovold: for some reason something in pulseaudio/wireplumber/pipewire (i'm vague on these) keeps crashing if i have the device enabled. if i disable the internal device it works fine with bluetooth and USB-C audio adapters
<jhovold>
steveej[m]: that looks like a pipewire issue, which is now also used for the camera so possibly not audio related
<jhovold>
perhaps you can try disabling the camera (e.g. in dt) and see if the problem goes away
<steveej[m]>
the camera is also disabled now. i'll do the diligence to only have the audio enabled and double-check the logs. should it work to only have audio output and not the microphone enabled?
<steveej[m]>
OTOH, could i just blacklist qcom-soundwire?
ungeskriptet has quit [Remote host closed the connection]
<jhovold>
steveej[m]: you shouldn't need to disable audio, haven't had any such issues but I am using pulseaudio here
chrisl has quit [Ping timeout: 480 seconds]
kuruczgy has quit [Remote host closed the connection]
kuruczgy has joined #aarch64-laptops
kuruczgy has quit [Remote host closed the connection]
kuruczgy has joined #aarch64-laptops
kuruczgy has quit [Remote host closed the connection]
kuruczgy has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe_ is now known as tobhe
<erebion[m]>
When the X13s runs out of battery while in suspend/s2idle, it starts slowly turning the Thinkpad logo LED on and off and pressing the power button (with the charger plugged in) does not turn it back on and I need to push the reset button several times and try to power it on again and again until it finally does.
<erebion[m]>
Do we have a way of preventing that?
<erebion[m]>
I don't always have a needle with me to push the reset button, so that's annoying, lol
<tobhe>
jhovold: thanks, forwarded to the relevant parties
<tobhe>
davidinux: thx, I'll make sure to include that in the next build again, wasn't high priority because not enabled by default until we have safe limits
<davidinux>
you have Srini's patch that implements safe limits in kernel
<davidinux>
that said, one can still drive master all the way up ...
<davidinux>
not sure to what effect
<davidinux>
the other patch implements the two speakers - w/o it you only get sound from one
<lak>
thanks. hmm, mine isn't suspending when closing lid, at least not indicated by the red led on the lid
<jhovold>
no, that led is not supported yet
<jhovold>
depending on which laptop you have, the lid switch should be supported and you go into suspend
<jhovold>
not just the lowest power mode yet
<kalebris>
is there any indication/guess on when lowest power mode will be reached?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
lollarsheher[m] has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
davidinux has joined #aarch64-laptops
davidinux is now known as Guest1381
davidinux has joined #aarch64-laptops
Guest1381 has quit [Ping timeout: 480 seconds]
<freekurt[m]>
5 months
<freekurt[m]>
Keep in mind that I just made that number up out of thin air just because I like guessing games.
<bamse>
freekurt[m]: it's not a completely unreasonale guess...
gwolf has quit [Ping timeout: 480 seconds]
gwolf has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<freekurt[m]>
Cool!
<Jasper[m]>
Hmm hope Konrad can get it in a working state
<Jasper[m]>
(and/or other people, last thing I saw was Konrad working on it)
gwolf has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
gwolf has joined #aarch64-laptops
<bamse>
that said, what we will achive is to be able to hit the lower power mode...this will likely unearth some issues, and per the power measurements on x13s even in this mode there's still a fair amount of power being consumed
<Jasper[m]>
From what I gathered, there's plenty people willing to test things on the x13s here :p
<Jasper[m]>
And any improvement is an improvement, even if it's just seconds more battery life
<Jasper[m]>
I did see some PMU related commits in Konrad's newsleep branch land in 6.13 DT pull.
<bamse>
it's not seconds of battery life...it's days
<Jasper[m]>
I'm sure it is, I'm mostly referring to the last part of your message
<Jasper[m]>
"A fair amount of power" sounds fairly negative, but any tuning is welcome to me (can't speak for others).
<Jasper[m]>
Having things improve from a day to several days is amazing
<bamse>
hehe, yeah you're right...it's a really nice improvement, and then there's more to squeeze out of it :)
<Jasper[m]>
Can't wait :D
<Jasper[m]>
Already extremely happy with the thing as-is.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
gwolf has quit [Ping timeout: 480 seconds]
gwolf has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<maz>
jhovold: I'm travelling at the moment, and probably won't be doing anything computer related until Monday. but I'll definitely give it a go once I'm back!
alpernebbi_ has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
copticcurse has joined #aarch64-laptops
copticcurse has quit []
SpieringsAE has joined #aarch64-laptops
<rsalveti>
jhovold: thanks, forwarded that internally as well (including the edk2 pr), interesting that while EBS fails on CRD do we have reports of the same boot failure when loading linux there?
<rsalveti>
wonder if things are just behaving differently with lenovo due different timings or similar during runtime
<tobhe>
in our Ubuntu bug tracker we have only seen reports for the T14s
chrisl has joined #aarch64-laptops
lak has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
HP X14 also was prone to fail, but the grub-x1e fixes seem to have circumventend them
alpernebbi_ has quit []
hightower3 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<farchord>
Good evening ladies and gentlemen, happy thanksgiving to anyone celebrating it today!
<farchord>
Question for you all: I know sound, camera and USB-A is still very much WIP. What about battery management? I just made a fresh disk with Fedora Rawhide, and I was pleasantly surprised that it now seems to be fetching bios time, which is awesome! Is there a fix for battery management? Is there something I should be copying from windows, firmware-wise?
<kuruczgy[m]>
For x1e, pd-mapper + adsp fw should be enough to get battery status
jhovold has quit [Ping timeout: 480 seconds]
<ppd[m]>
^
<ppd[m]>
I know for a fact that is the case. Confirmed on gentoo