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
<steev> not sure if it helps anyone, but this is the dmesg output i got resuming from suspend earlier on 6.9-rc5 and having the wifi shit itself - http://sprunge.us/0INHgo
possiblemeatball has joined #aarch64-laptops
<dgilmore> steev: looks like things I've seen before
KREYREN_ has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
<steev> it does not happen here on 6.8
<konradybcio> I'd be surprised if there were no issues :p
possiblemeatball has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #aarch64-laptops
<albsen[m]> my Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter is acting up. its not loading. modprobe ath11k_pci -r ... and so on I was able to wake it up (only after the machine crashed). the x13s install used to work just fine on my previous x13s (with 5g adapter)
<albsen[m]> I'm on debian testing
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
<albsen[m]> I've checked and it looks like the correct firmware is installed: ls /usr/lib/firmware/ath11k/WCN6855/hw2.1 64%
<albsen[m]> amss.bin board-2.bin m3.bin regdb.bin
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
KREYREN__ has joined #aarch64-laptops
KREYREN_ has quit [Remote host closed the connection]
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_sdbox2 has joined #aarch64-laptops
<albsen[m]> fixed the ath11k_pci loading issue using the most recent firmware from linaro (thx linaro) https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware installed it as described into /lib/firmware and now all is working.
<Segfault[m]> alright i'm giving up on the SN740 in the X13s, i've tried everything i can think of and it's still giving me random dropouts, i've ordered a drive which uses a phison controller that'll hopefully work better
KREYREN_ has joined #aarch64-laptops
KREYREN__ has quit [Ping timeout: 480 seconds]
<steev> albsen[m]: the latest in linaro is the same as in linux-firmware
<steev> though
<steev> debian testing doesn't have that version yet
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #aarch64-laptops
jglathe_x13s has quit [Ping timeout: 480 seconds]
<steev> albsen[m]: which kernel btw
<albsen[m]> <steev> "debian testing doesn't have that..." <- hm, I checked sid ... I have both in my apt but preference is given to testing
<albsen[m]> <steev> "albsen: which kernel btw" <- 6.7.1-jglathe-20240129
<albsen[m]> custom build from the repo
<albsen[m]> this is the latest commit I have in there: commit d7da5073ce3d88a0ed4dc55dd4dc2ae200b41898 (HEAD -> jg/blackrock-v6.7.y, origin/jg/blackrock-v6.7.y)
<albsen[m]> Date: Thu Jan 25 19:55:14 2024 -0800
<albsen[m]> for context, this all used to work just fine on my previous x13s (16gb, 5g, touch screen) now I upgrade to (32gb, no 5g, touch screen) and got issues that were resolved with the firmware install
<Segfault[m]> hey jhovold have you poked at the ec in the x13s at all by any chance? it seems to live at 0x28 on i2c8 and its driver appears to be fully implemented in acpi afaict so far
<Segfault[m]> i'm tempted to have a play with it and maybe see if i can lower the s2idle power draw at all
KREYREN_ has quit [Remote host closed the connection]
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
<jhovold> Segfault[m]: no, I haven't but I think konradybcio has poked at it
* travmurav[m] wonders what does that poor thing even do beyond being a keyboard scanner given all the charging stuff is in dsp firmware and (afaiu?) only allows "online" charging
<jhovold> it won't help with the s2idle power consumption, though
<Segfault[m]> ah damn
ungeskriptet has joined #aarch64-laptops
<Segfault[m]> travmurav[m]: > * <@travmurav:matrix.org> wonders what does that poor thing even do beyond being a keyboard scanner given all the charging stuff is in dsp firmware and (afaiu?) only allows "online" charging
<Segfault[m]> i mean as far as i can tell so far the only stuff this i2c endpoint might even control is the keyboard backlight and the little blinking led on the back of the lid lol
<travmurav[m]> ah kb bl would make sense yeah
<travmurav[m]> hm on windows the led turns off when the device is off/suspended?
<Segfault[m]> yeah the led starts flashing slowly
<Segfault[m]> and it automatically turns off the keyboard backlight
<travmurav[m]> I'd assume it's just AP_SUSPEND line from the pmic connected to the ec tbh, this is what aspire1 has
<travmurav[m]> I guess someone who has schematics could confirm that
<Segfault[m]> ¯\_(ツ)_/¯
<travmurav[m]> but I'd expect it would do the same on linux when someone fixes stuff that holds the soc from going low pwoer
<Segfault[m]> i do see an acpi dsm notifying the ec of state changes though so that's why i'm curious
<travmurav[m]> I think I skimmed at the thing and most of it was wmi stuff?
<travmurav[m]> not sure which acpi I was looking at but iirc it was x13s
<travmurav[m]> did someone try to decode wmi blobs to get strings from them?
<travmurav[m]> on aspire1 there are fields to read the mac address :P
<Segfault[m]> dunno but around line 3113 of the x13s dsdt.dsl on the aarch64-laptops git repo there's a bunch of calls to SB.I2C9.ECNT, and the function they're in gets called by windows to notify of a bunch of different s0ix related state changes
<Segfault[m]> they all seem to write different magic bytes to an i2c register
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_sdbox2 has joined #aarch64-laptops
f_ has joined #aarch64-laptops
<Segfault[m]> oh the ec endpoint handles hotkeys too
<Segfault[m]> it seems like it triggers a gpio interrupt and then you read a register to get the key
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
<KieranBingham[m]> Running libinput debug-events (fedora-rawhide, x13s) I get events from 'some' of the function keys, such as volume, brightness, but not all of them. F7, F8, F9, F10, F11, F12 all seem to generate no event (where they are pictured as switch monitor, flightmode, disable camera, phones? and a star?) ... Does anyone know how/why they don't make an event all the way into libevent/wayland? Are they being managed by the bios directly
<KieranBingham[m]> or such ?
<KieranBingham[m]> (that is they generate Fx signals, but not the event/signal when fnlock is not enabled)
<travmurav[m]> probably handled via WMI and not hid-over-i2c like Segfault suggested
<travmurav[m]> so one would need to write a driver for that to catch the events and present them via a dedicated input device
<Segfault[m]> i can have a look at it some time soonish, i've somehow borked the linux install on my old ssd though and i don't feel like hacking something together until the new one arrives (and hopefully works unlike the sn740)
<KieranBingham[m]> aha, I didn't realise the conversation above was actually closely related ;-)
<Jasper[m]> @konradybcio time to post ec work here
<Segfault[m]> oh it seems like there's some event system that sends the same codes as acpi thinkpad ecs
<Segfault[m]> there seems to be stuff related to hotkeys, thermals and some hid helper
<Jasper[m]> Actually wait I may have Konrad's tree for ec worj
<Segfault[m]> oh nice that'd be useful
<Jasper[m]> https://github.com/somainline/linux/commits/topic/ecdumper might only do as described, but there may be some work done otherwise
<travmurav[m]> tbh I'd assume the "thinkpad" wmi driver in x86 would be compatible with ^^ acpi but pretty obvious it would be challenging to use
<travmurav[m]> think-lmi.c I think
<Segfault[m]> i was looking at platform/x86/thinkpad_acpi.c since it seems to have the EC code stuff
<travmurav[m]> that feels like older stuff to me, dunno if they use both or moved on to wmi only
<Segfault[m]> i saw reference to someone getting an error from that driver on a T14 so it seems to be getting use on new machines
<travmurav[m]> I guess can ^F for the pnp ids
<Segfault[m]> anyway i doubt it'd be super useful here but once i've got a working environment i'm more than willing to throw together a quick PoC driver
<travmurav[m]> but well, since we use DT, would need to do something like what I did for aspire1 and talk to the ec directly