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
<tobhe>
I take that back, didn't update the dtb correctly... the screen stays black unless I remove those two
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
enyalios_ is now known as enyalios
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
itsme5n has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<gabertron>
Ok thanks!
itsme5n has quit [Ping timeout: 480 seconds]
itsme5n has joined #aarch64-laptops
itsme5n has quit [Ping timeout: 480 seconds]
<steev>
konradybcio: i finally got the time to reboot the c630 a few times... 8 reboots tested - reboots 1 and 5 gave a blue screen (no qr code, just the screen was blue) and rebooted. boots 2 and 6 gave a blue screen (no qr code, just the screen was blue) but did NOT reboot. boots 3 and 8 were a black screen with a reboot. boot 4 and 7 were the same smmu message as before, but ended up at a busybox prompt (but no usb)
<steev>
that is with the .reset patch added on top of the dtsi patchset
<steev>
gwolf: BATTERY_LENOVO_YOGA_C630 is the option in 6.11; and i'm like 90% positive i saw lumag submit a merge request for it to the kernel repo (i thought it was merged, maybe it isn't?)
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
itsme5n has joined #aarch64-laptops
itsme5n has quit [Remote host closed the connection]
itsme5n has joined #aarch64-laptops
MattSuiche[m] has joined #aarch64-laptops
<MattSuiche[m]>
Hi everyone! Anyone has had any luck with the latest T14S?
<Jasper[m]>
<MattSuiche[m]> "Hi everyone! Anyone has had..." <- There should already be a device tree upstream iirc
<Jasper[m]>
There are people with out of tree patches here and there
<steev>
lumag: no, it's not tqftpserv related, but i'll let gwolf look if he wants, i'd rather try to figure out wtf is going on with audio
<lumag>
Ah. Yeah. I have been pinging srinik, but got no response up to now.
<lumag>
Maybe I should take a look on my own
Lucanis has joined #aarch64-laptops
<steev>
i don't *think* it's in the codec, i think it's in soundwire, because we used to be able to short circuit it by putting hte qcom.c from 6.6 into place
macc24 has joined #aarch64-laptops
<MattSuiche[m]>
Jens Glathe: After the grub menu when I select `Ubuntu (Lenovo Thiknpad T14s)` the screen freezes
<steev>
lumag: actually speaking of the c630... one thing i've noticed is that it doesn't export/report charge_* which seems to break anything not using upower (so e.g. waybar)
iivanov has joined #aarch64-laptops
<JensGlathe[m]>
Matt Suiche: there appears to different i2c wiring, different panel data. For my own case, hp Omnibook X14, I get a dark screen as soon as I try to enable the USB4 retimers. Maybe similar there.
<JensGlathe[m]>
From what I read from tobhe he got his working by removing some commits. I can put this in V7.
_xav_ has quit [Ping timeout: 480 seconds]
<lumag>
steev, that's an ACPI thing. It's either charge or power
<lumag>
If you take a look at the ACPI battery code, it will also export only one set of attributes
_xav_ has joined #aarch64-laptops
<JensGlathe[m]>
Matt Suiche: as I suspected, its the USB4 retimer stuff for t14s
<MattSuiche[m]>
How did you troubleshoot this
<JensGlathe[m]>
Oh I just looked into the commits tobhe was referencing, and I had the same issue here with my hp X14. So no real troubleshooting with physical hardware
<travmurav[m]>
steev: fwiw there are many (non acpi) fuelgauges that don't report either and only report "capacity" (%) so I'd say those tools are just wrong to assume it's provided by acpi
<travmurav[m]>
And then you have extra sad ones that don't even have that...
alpernebbi has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
<steev>
travmurav[m]: yeah it probably is, it used to work, so it's probably some assumption in a change
<JensGlathe[m]>
The only thing is that mdss_dp2 is not connected (or shouldn't be)
<macc24>
why is *something* eating my gpio-keys node? i'm trying to add lid switch to lenovo-yoga-slim7x.dtb and no matter what, the added gpio-keys node itself doesn't make it to bootede linux system - it's there in the esp partition
<macc24>
there's just no trace of it in /sys/firmware/fdt, or dmesg
<JensGlathe[m]>
abelvesa:@tobhe had to revert the USB4-retimer patch to get his T14s up with display
<gwolf>
I tried to find what can be causing the issue, but couldn't. I suppose it's something between lines ~692--757 of the diff, that's where the firmware upload is handled, but TBH have no further clue.
<robclark>
idk if that is the exact path we want, IIRC there were multiple vivobook variants, and if so I'm not sure if they have the zap fw signed the same way
<robclark>
qcdxkmsuc8380.mbn would have to be copied from windows partition, to /lib/firmware/qcom/x1e80100/vivobook/qcdxkmsuc8380.mbn
<robclark>
you probably don't need to rebuild kernel, just the dtb
<MrCatfood[m]>
i'm new to this can you link me some guide how to do that? i'm new to this advanced level stuff
<robclark>
what is /sys/class/dmi/id/board_vendor and /sys/class/dmi/id/product_name on the vivobook? I guess we should use that for the fw path
<macc24>
idk, those were the ones that matched what i saw on my yoga slim 7x
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
i put them here for the one i had: qcom/x1e80100/ASUSTeK/vivobook-s15/qcdxkmsuc8380.mbn
<SpieringsAE>
but I didnt check the dmi names, didnt know about that
<SpieringsAE>
but jeah, I dont have it anymore so cant check
<macc24>
what you *should* check is either firmware-name in dts file, or what path does msm driver
<SpieringsAE>
jeah i put it in the dts hahaha
<SpieringsAE>
like that
<SpieringsAE>
I think ASUSTeK is correct, but I doubt vivobook-s15
* macc24
prays there's a vivobook-s15 in dmi product_name
<robclark>
for non dev-mode devices you defn need firmware-name in dts file
<robclark>
crd and possibly devkit could use the test-signed zap fw, but not production laptops
<SpieringsAE>
for some reason, the only place the asus vivobook MA0001W with 32gb of ram is only available in europe in the baltic states lol, estonia and lithuania, its pricier than I hoped though 1500 eur compared to 1300, was hoping for a price bump of only 100 eur
<MrCatfood[m]>
<macc24> "Mr.Catfood: this code snippet..." <- i had to change the script a bit but ran it, what should i do next? simple reboot?
<macc24>
MrCatfood[m]: sure why not
<macc24>
oh right i hope you're not booting from usb
SpieringsAE has quit [Remote host closed the connection]
<JensGlathe[m]>
abelvesa: thank you for pointing out the patch. I have removed mdss_dp2 from my dts, and now it boots with display. Will check if these retimers do something now.
<JensGlathe[m]>
Do you have a tplg file per chance to work from?
srinik has joined #aarch64-laptops
<MrCatfood[m]>
<macc24> "oh right i hope you're not..." <- i am
<MrCatfood[m]>
but its not live boot
<macc24>
ok if you see filesystem errors after boot then remove either adsp or cdsp firmware, for me having them caused usb devices to re-enumerate
<steev>
oh wait no, i misread, fairphone is the upstream patch, sorry
<lumag>
Well, if they still have it then it wasn't upstreamed
<steev>
it's not from fairphone (afaik); it seems it's from debianonmobile - but basically changing line 41 of the debian patch to `strcat(path, dirname(firmware_value));` fixes loading the firmware here
tobhe_ is now known as tobhe
<steev>
in 2 hours i can test if removing their patch (it's supposed to be to also look in updates) works
<steev>
unless gwolf wants to remove the debian patch, build the package and test
<steev>
gwolf: actually could you please test that as well? just comment out the patch in the series file and build the package? should take ~30 seconds
chrisl has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<kuruczgy>
macc24: FYI I already tried to get the lid switch working on the yoga 7x a while ago, here is what I learned:
<kuruczgy>
Looking at `/sys/kernel/debug/gpio` over SSH I could not see gpio92 change when closing the lid
<kuruczgy>
I then dumped the gpio registers in windows using Konrad's "poor man's JTAG" method (https://konradybcio.pl/windbg/), and saw that gpio92 WAS changing with the lid state in windows
<kuruczgy>
I then went and dumped all other GPIOs on windows, and tried to manually toggle the ones set to output in windows but not in linux (the theory being that maybe some other gpio is needed to "enable" the sensor), but no luck
<kuruczgy>
I am not confident that my search was exhaustive, but I think I tested most such gpios
<kuruczgy>
But it would be awesome if you wanted to drill deeper, I find that not having the lid switch working is a pretty big usability pain point
srinik has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
sibis: have you had a chance to check it already?
kettenis_ has quit [Remote host closed the connection]
kettenis has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
krei-se has quit [Read error: Connection reset by peer]