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]
krei-se has quit [Ping timeout: 480 seconds]
krei-se has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
weirdtreething_ has joined #aarch64-laptops
d0pefish5 has joined #aarch64-laptops
weirdtreething has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
<icecream95>
SpieringsAE: I have noticed the EC do one thing on its own... the keyboard backlight is turned off when the lid is closed (independent of the system being suspended or not)
<icecream95>
But I usually keep the backlight off, so that feature is not much use for me
<travmurav[m]>
some devices hard-wire lid switch to turn off display backlight, won't be surprised if they did the same for kb eds
<travmurav[m]>
leds
<travmurav[m]>
i.e. completely outside of firmware
<icecream95>
huh interesting. Well the EC can at least remember the colour of the keyboard backlight, I don't expect *that* is done in hardware
sally has quit [Quit: sally]
<travmurav[m]>
well yes, but I mean they could have an extra transistor hardwired to the lid switch that would force leds off even if ec still drives them (though I guess might be unlikely and instead ec fw just knows the lid state)
<icecream95>
I also wonder whether the brightness and colour are controlled by different hardware, since setting them is done in two different ways
<icecream95>
(brightness through the keyboard HID interface, and colour through the EC. Both on the same I2C bus.)
<travmurav[m]>
well I'd assume in the end it's same pwm on 3 led "lines" (i.e. both brightness and color change the pwm values of the same thing)
<travmurav[m]>
so perhaps just some weird mess where HID one is there because there is a generic windows api for kb brightness but not for color so "use our app that hits special custom api"? xD
chrisl has joined #aarch64-laptops
* travmurav[m]
finds it funny his laptop has all the software and hardware for kb backlight, just not the actual leds and keycaps
<travmurav[m]>
they didn't even bother removing transistors and connectors from the motherboard BOM
<travmurav[m]>
but I guess to counter my own argument, I don't think aspire1 gates kb leds on lid state in hw, only display backlight
<icecream95>
I don't think the HID feature reports used are standard, maybe it's just because there is a Fn key for changing the brightness, so the Windows keyboard driver needs to be able to easily change the setting without going through the EC driver
<travmurav[m]>
uh is that fn keycombo reported to the OS and not just intercepted by ec?
deathmist has quit [Quit: WeeChat 4.5.1]
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
travmurav[m]: Yes, a vendor report is used for it. Fn-lock is also toggled in software, and brightness up/down are not standard HID (so brightness and volume can be changed at the same time!), but none of that is as bad as the external display key pressing LEFTMETA, tapping P, waiting a second, and *then* releasing LEFTMETA
<travmurav[m]>
duh lol
<travmurav[m]>
but I guess having software fn is at least nicer to remap stuff than full firmware fn handling
<icecream95>
Also the EC is a little buggy and sometimes keys like Scroll-Lock (Fn+K) or PrtSc end up held down randomly, or other keys don't work, or...
<icecream95>
I miss the simplicity of cros-ec-keyboard...
<icecream95>
travmurav[m]: "not the actual leds and keycaps" Why would you need special keycaps for a backlight keyboard, when you can just feed 5W to the LEDs and have something that's bright enough? (sigh...)
<travmurav[m]>
LOL
<travmurav[m]>
I guess white opaque keycaps would even somewhat "work" xD
<icecream95>
It is a bit insane that keyboard backlight power consumption can be higher than display power consumption
<travmurav[m]>
yeah...
<travmurav[m]>
I guess it's arr gee bee? xD
<icecream95>
lots and lots of tiny little arrs, gees, and bees
<icecream95>
You can even see them through the bottom of the case
* travmurav[m]
hates rgb leds
<travmurav[m]>
well I guess it's workable as long as they're not used to illuminate something else
<icecream95>
travmurav[m]: Guess you wouldn't want a display with 13996800 of them then?
<travmurav[m]>
but well, just need to learn touchtyping and then can save 5W /s
<travmurav[m]>
(but i meant more like bad CRI when those leds are used to "reflectively" illuminate something)
<travmurav[m]>
or I guess when they're far apart enough that you see the separate sources and not just mixed light xD
sally has joined #aarch64-laptops
<icecream95>
On Windows the temperature is sent to the EC every second, but I don't know if it actually controls the fans or if it is just keeps a watchdog at bay (said watchdog is annoying for kernel debugging!). Anyway trying to send the same commands from Linux has no effect, so I guess an enable command is missing
funderscore is now known as f_
<albsen[m]>
tobhe_: 6.14-rc1-1 (from Jens Glathe google drive) is the last working version, 6.14-rc2 (from google drive crashes on 5g) and 6.14.0-5 (the one installed from launchpad) crash on 5g
<JensGlathe[m]>
Yeah I'm in the bisecting trenches on 6.14-rc3, so far no lock and lots of dark energy
<JensGlathe[m]>
s/lock/luck/
<albsen[m]>
as far as my tests go, 6.14-rc1-1 to rc2 something broke
<albsen[m]>
hope this helps
<albsen[m]>
on the flip side, it appears to be that this was the only full crash I saw on 6.14 so maybe if I simply dont use 5g I can use the device for my work :) I'll also try with other 5g routers and see if that makes a difference
<albsen[m]>
ok, tried my mobile netgear router in 5G mode: I can connect to it using 5G, but the minute I disconnect (I can see the deauthenticating msg in kernel.log) it crashes (the screen goes dark blue). so my asus home router the system crashes immediately during the connect. on netgear it crashes during disconnect in 5g.
<JensGlathe[m]>
I've had this deauthenticating bug (but with Wifi) on rc1 and rc2 too, gave a null pointer deref in the kernel. Call appeared to come from wpa-supplicant.
<albsen[m]>
rc1-1 is working for me
<albsen[m]>
well, let me try deauth
<albsen[m]>
ok, deauth on rc1-1 is also broken
<JensGlathe[m]>
it kills the box?
<albsen[m]>
yes, blue screen
<albsen[m]>
full crash, I'm connected via ethernet at the same time to tail dmesg
<albsen[m]>
and all stops
<JensGlathe[m]>
yea. I found the dev kit dead for several days over night, last log entry was deauth and kernel error at 00:00
<albsen[m]>
how do u get the kernel errors?
<JensGlathe[m]>
journalctl -b -1
<albsen[m]>
ok, thx
<albsen[m]>
I'll restart using it daily on 2g lets see if I encounter anything else
<icecream95>
I think the null deref in ath12k_mac_handle_beacon_miss_iter can be worked around by just returning before the line with ath12k_ar_to_hw if ar is NULL... though haven't bothered compiling a kernel with that changed yet
<icecream95>
(It seems the problem there is: I suspect that previously arvif->ar was unconditionally set, but now it might only be set for interfaces that are up, but the check against arvif->is_up is too late in the function)
<icecream95>
albsen[m]: JensGlathe[m]: ^^
<albsen[m]>
thx for the pointer
krei-se has joined #aarch64-laptops
<albsen[m]>
noticed another thing with 6.14.0-5 it's missing bluetooth
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
This is working here
icecream95 has quit [Ping timeout: 480 seconds]
<albsen[m]>
its working on all kernels I downloaded from google drive, only the one coming from launchpad is having that issue
<albsen[m]>
and apt is refusing to install the version you have on google drive (6.14.0-5.6) without mixing packages from launchpad
<JensGlathe[m]>
this mixing shouldn't be too problematic, same config
<JensGlathe[m]>
and I can add do_tools to my config if they build
<JensGlathe[m]>
finally. the first bisect good that wasn't expected
chrisl has joined #aarch64-laptops
<tobhe_>
albsen[m]: 6.14.0-13.13 should fix bluetooth
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
rmsilva has joined #aarch64-laptops
rmsilva- has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
krei-se- has joined #aarch64-laptops
krei-se- has quit []
krei-se- has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
krei-se- has quit []
krei-se has joined #aarch64-laptops
krei-se has quit []
krei-se has joined #aarch64-laptops
krei-se has quit []
krei-se has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
<steev>
there are a lot of ath12k changes on the wireless mailing list