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
<enyalios>
on the x13s is there a way to programmatically control the keyboard backlight
<enyalios>
like something in /sys or something?
derzahl has joined #aarch64-laptops
<clover[m]>
I think that's controlled by bios level firmware
derzahl has quit [Remote host closed the connection]
<push>
It boots to where the x13s sits and waits for a long time, but sadly doesnt seem to go further even after ~15 minutes
alfredo has joined #aarch64-laptops
mcbridematt has quit [Ping timeout: 480 seconds]
matalama_ has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
hightower2 has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
matalama_ has quit [Quit: Connection closed for inactivity]
<_[m]1>
<steev> "dunno but i've seen people say..." <- nah for EOS you git clone a repo and run install script - maybe there's an option to do FDE there - haven't investigated, just followed instructions of clover
abcdw has quit [Remote host closed the connection]
abcdw has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<dgilmore>
robclark: got a weird one for you. in Fedora 39 on a x13s I have found I have to add rd.driver.blacklist=msm to my bootargs, if I dn't the videostack crashes.but delaying the setup is enough to have it work fine. have you seen anything similiar?
<Jasper[m]>
I've seen it on msm8916, neat trick was to load in wifi firmware first, but I'm not sure how applicable that is to this situation
<travmurav[m]>
don't think it's the same issue.... That one was to make sure the panel driver loads before msm but I think either nowdays or on the new platforms it's not an issue anymore...
alfredo has quit [Quit: alfredo]
hightower2 has quit [Ping timeout: 480 seconds]
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<robclark>
dgilmore: got dmesg? Maybe something with something probing in a different order? I've not had that issue on my x13s+f39 but I'm not using distro kernel
<robclark>
oh, wait.. I guess I'm still on f38 (but wouldn't expect that to matter)
<dgilmore>
robclark: not with the crash. Is there a way to get the serial console?
mkrawczuk has joined #aarch64-laptops
<robclark>
hmm.. not that I know for... bamse ^^^
<robclark>
I guess even if you get to emergency console or login, you have no display? Can you ssh to it?
hightower2 has joined #aarch64-laptops
<steev>
that definitely seems odd, what kernel version is f39?
alfredo has joined #aarch64-laptops
<bamse>
robclark: someone here said that there's a debug connector, with the uart on
<dgilmore>
6.5.4
<robclark>
I was using 6.5.something at one point..
iivanov__ has quit [Quit: Leaving]
<owc[m]>
push: juergh was looking into https://bugs.launchpad.net/ubuntu-concept/+bug/2037204. But unfort. we can't reproduce nor have any log signaling for the "crashes". Do you by chance have anything hints/ pointers to add to the matter?
<qzed>
Might be slightly off-topic, but does anyone know if any suspend/resume related things regarding tty/serdev, workqueues or threads got changed from 6.4 to 6.5?
<qzed>
We have an issue in Surface devices with the EC comms when entering suspend: If we send a message via serdev during prepare() it gets to the EC, but we don't get any responses until we resume
<qzed>
it's like some thread/workqueue is frozen
<dgilmore>
robclark: I will install rawhide's kernel and try. I am in the camp I want it to be simple for all.
<dgilmore>
does anyone know the magic link to have the 5g modem automatically unlock?
<clover[m]>
if you don't have that file, make one and link it to the 105b script
<dgilmore>
cheers, was not sure what the rightid was since they seem to be usb ids but this is showing up as pci
<robclark>
dgilmore: are you able to get any splat / error msg on screen that you can get a picture of? You might need to remove `rhgb` and add `text` to kernel cmdline
<robclark>
I'm spoiled on chromebooks, with suzyq + console-ramoops
<robclark>
dgilmore: hmm, maybe something goes wrong with probe-defer.. I guess some dependency which is built as a module? Maybe you could attach .config to https://gitlab.freedesktop.org/drm/msm/-/issues/35 ? And also that new splat
<robclark>
I guess it comes down to some under-tested -EPROBE_DEFER path..
<robclark>
could you add that to the gitlab issue, that one is probably something for lumag or abhinav to look at
<steev>
i thought we had that one before
<push>
owc[m]: its running firmware 1.57 and it still has windows installed in the first partition, i installed ubuntu concept on the second partition, then updated it to mantic, its totally up-to-date
<push>
owc[m]: i've been trying to get a log of it happening but it doesnt seem to write anything, it just resets
<steev>
push: this the same one that had the bluetooth issues?
<push>
it really seems like it happens more often when bluetooth is loaded, but that's not enough to totally prevent it
<steev>
what is your ambient temperature?
<steev>
actually, i don't think ubuntu use my make it hotter patch
<push>
its not hot in here, i live in the midwest
<push>
its not hot to the touch or anything
<push>
i was using it off the charger last night while it was building stuff and it didnt do it
<push>
theres a couple seconds where the screen freezes then it resets
Libre___ has joined #aarch64-laptops
<Jasper[m]>
Still having crashing issues after luks unlock :(
<push>
owc[m]: Im confident is saying now that the crashes don't happen when cinnamon is running in software rendering mode