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
<craftyguy>
bamse: I don't see anything like that cycling in the logs... MM startup basically ends with this: https://bpa.st/JOYA
<craftyguy>
I have the full debug log from MM after it starts up, but I'm always hesitant to send that (I'm not super confident in my ability to redact PII or whatever from it :P)
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
abcdw has quit [Read error: Connection reset by peer]
adamcstephens has quit [Read error: Connection reset by peer]
adamcstephens has joined #aarch64-laptops
adamcstephens has quit [Ping timeout: 480 seconds]
indy_ is now known as e-ndy
e-ndy is now known as indy
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
nscnt[m] has left #aarch64-laptops [#aarch64-laptops]
mcbridematt has quit [Read error: Connection reset by peer]
<martiert>
to unlock the wwan interface. Does it suffice to have a symlink like: `/etc/ModemManager/fcc-unlock.d/105b:e0c3 -> /usr/share/ModemManager/fcc-unlock.d/105b`, or does the symlink in the end there also have to be names `105b:e0c3`? I have this link with ModemManager 1.20.6 and the 6.6.6 kernel from steev with the `laptop_defconfig`. and it complains that the interface can't be
<martiert>
enabled due to an invalid transition
<jhovold>
martiert: that should be enough, MM 1.22 just adds another symlink 105b:e0c3 -> 105b
<jhovold>
in /usr/share/ModemManager/fcc-unlock.d/
<martiert>
jepp, that's what the patch looked like. It keeps cycling on the state change from `disabled -> enabling`, and stops in state 4/10 with `Invalid Transition`
<jhovold>
that sounds like what bamse what describing above, though
<jhovold>
try creating the intermediate link just to rule that out
<jhovold>
I'm pretty sure bamse was using the modem with MM 1.20, and it didn't look like there had been any changes to the unlock script since then
<jhovold>
but maybe something else changes under the hood that requires MM 1.21, you could try that as a second step
<martiert>
aaah, I see there's some issues running the unlock script. Running MM with debug output shows me: `[modem0] couldn't run FCC unlock: fcc unlock operation finished with status 127`
<jhovold>
agl: I'd generally suggest maintaining a local patch on top of johan_defconfig with your local changes that you rebase and then generate when updating
<jhovold>
but you could just do 'make oldconfig' as well
<jhovold>
remember to enable the camera clock controller if you use steev
<jhovold>
steev's branch, though
<jhovold>
otherwise the interconnect will not reach the sync state and you'll be wasting power
<martiert>
seems like I was at least missing `qmicli` on my system. Adding that and trying again
<martiert>
and adding that fixed it :)
<martiert>
craftyguy: this might the same issue you were having, as our issues seemd very similar
<jhovold>
martiert: good to hear you found the issue, but shouldn't libqmi be pulled in by MM?
<martiert>
according to the MM docks it shouldn't, as it's not a direct dependency on MM. Normally those scripts use either qmicli or mbimcli, none of which are normally pulled in my MM
<konradybcio>
jhovold im not sure if it's the same bug.. install vscodium (the microsoft-free version, not sure if the spyware one has the issues, probably it does) and try just using it for a couple minutes
<konradybcio>
it will start jumping in time on parts of the screen
<konradybcio>
very annoying
<jhovold>
konradybcio: that one's easily fixed, just use vim ;)
<konradybcio>
jhovold that breaks my mouse.. unacceptable regression!
<jhovold>
mouse? what's that?
<jhovold>
are you coding or drawing pictures in MS paint?
<Jasper[m]>
jhovold: The thing on the x13s wiki that you say is supported upstream :^)
<konradybcio>
i mainly use it for jumping around the code that fits within one screen (and i use an ultrawide big one..), gaming reflexes help me get the cursor where i want far faster than with keyboard movements
<jhovold>
Jasper[m]: I think I only mentioned the touchpad ;)
<jhovold>
konradybcio: sounds bad for your wrists
<konradybcio>
jhovold just one :P
jglathe has joined #aarch64-laptops
<robclark>
jhovold: not really.. are you just seeing tearing? If so, with Xorg and non-compositing window mgr, that is just expected
<Jasper[m]>
It specifically happens if you move the cursor over the window and do something that changes the content
<Jasper[m]>
It also happens if something else on the screen moves (Fluffychat is showing a loading animation that makes it bug out consistently)
<robclark>
window mgr doing front buffer rendering?
<robclark>
I don't see anything like that w/ gnome-shell.. but looks kinda like what you'd get if you tried to do front-buffer rendering with UBWC
<jhovold>
robclark: perhaps that's what it is, xterm stays corrupted and moves up line by line if I scroll down
<jhovold>
haven't seen anything like this on my desktop using same Xorg setup
<jhovold>
intel gfx
<robclark>
so, if it _stays_ corrupted then it is something else.. but transient issues can happen because you can't atomically update a region of a ubwc image
<jhovold>
ok, thanks, that what I thought
<robclark>
re: frontbuffer rendering, I did add `GBM_BO_USE_FRONT_RENDERING` a while back (CrOS has similar issue with stylus / fask-ink which uses front buffer rendering for lower latency)
<steev>
Jasper[m]: or you could take the patch i wrote as guidance and write a correct one :)
iivanov has quit [Quit: Leaving...]
DigitalPirate[m] has joined #aarch64-laptops
DigitalPirate[m] has left #aarch64-laptops [#aarch64-laptops]
<craftyguy>
martiert: I was missing qmi-cli, but installing it didn't seem to have much impact
<craftyguy>
in the MM logs, I see stuff like "[base-manager] port wwan0 not candidate" and "[modem0] net ports available but ignored"
<craftyguy>
(it detects wwan0 as a net port before that last message)
<craftyguy>
ok got a bit further by running parts of the fcc unlock script manually... mbim-proxy was also missing
<craftyguy>
signal is still 0% though
<Jasper[m]>
<steev> "Jasper: or you could take the..." <- That's fair, I'll take a proper look later. First have to get compiling the fedora kernel package working properly hahaha
krei-se has quit [Read error: Connection reset by peer]
<nerdboy>
it sounds like i should be able to boot 6.7 mainline at least to console?
<nerdboy>
so far it stops after efi stub loader
<Jasper[m]>
<jglathe> "moin" <- a...end?
<Jasper[m]>
<nerdboy> "it sounds like i should be..." <- Oh yeah it should basically fully work
<Jasper[m]>
Do you have some more info on your setup? Like what config you're using and such.
<jglathe>
@Jasper[m] all-day greeting in some regions
<Jasper[m]>
jglathe: Ah, thought it was a hyper specific german dialect version of "morgen"
<jglathe_>
it is, sorta - and got a life of its own
<steev>
ayyy nerdboy
<steev>
nerdboy: you probably need arm64.nopauth
<steev>
in your command line arguments
<nerdboy>
oooh, that one is not in the wiki...
<nerdboy>
i just need a usable boot stick so i can reinstall
<nerdboy>
that ^^ one boots other stuff fine using efi-grub
<nerdboy>
okay, now i have: GRUB_CMDLINE_LINUX="console=tty1 rootfstype=ext4 rootwait net.ifnames=0 efi=noruntime pd_ignore_unused clk_ignore_unused arm64.nopauth" and GRUB_DEFAULT_DTB=qcom/sc8280xp-lenovo-thinkpad-x13s.dtb
<konradybcio>
quite a command line, i must say
svarbanov has quit [Ping timeout: 480 seconds]
<jhovold>
nerdboy: i'm pretty sure I mentioned nopauth in the wiki:
<jhovold>
but I have a patch in my wip branches that allows you to omit it
<jhovold>
the hope was that that Lenovo and Qualcomm would fix their firmware and I could just drop the patch
<jhovold>
now I'll probably drop those patches from the wip branches instead so that the same command line can be used for mainline and wip
<steev>
we can still hope :)
<Jasper[m]>
No one at Linaro with a Lenovo/Qcom contact?
<steev>
if only we knew someone at qcom :(
<steev>
calebccff: fwiw, this is what i see on the c630 for audio - https://paste.debian.net/1303814/ no idea what that underflow is, or why we're getting it, have seen it here and there before, but with newer kernels it occurs every boot
<jglathe>
what with those guys from quic that do Gunyah
<steev>
hm?
<calebccff>
steev: tried getting 6.7 booting yesterday, noooo dice, can't get display up either with drivers built in or as modules
<calebccff>
link training fails or something
<calebccff>
well, it worked randomly once or twice
<steev>
if you're still using the 4 year old patches from bamse, try disabling the dp ports
<steev>
the ones on the usb
<calebccff>
heh, i dropped those and switched to lumag's
<calebccff>
so mdss_dp is disabledc
<steev>
ah
<jhovold>
Jasper[m]: last time I asked them about it they were still working on a fix for the nopauth issue
<jhovold>
that was a few months ago now, though
<Jasper[m]>
Bummer that there's a lack of communication
<Jasper[m]>
steev: Hmm, Fluffychat does not like that image
<Jasper[m]>
or message
<Jasper[m]>
It's broken
<steev>
maybe it dislikes 2 urls?
<steev>
usb also seems broken on it, since lsusb returns nothing
<steev>
but it does boot and give me display
<nerdboy>
doh! it's there...
<nerdboy>
i blame my borrowed old-guy eyes
<nerdboy>
also
<nerdboy>
i was still on 6.6.8 and not 6.7
<nerdboy>
aaand with arm64.nopauth it does boot 6.6.8 so there ya go
<nerdboy>
i guess the iommu args are not needed with latest mainline?
* nerdboy
updates his own dumb wiki page
<jglathe>
with the recommendations from @jhovold it doesn't only boot, it's also quite snappy. "rootwait pd_ignore_unused clk_ignore_unused arm64.nopauth efi=noruntime iommu.passthrough=0 iommu.strict=0 pcie.aspm.policy=powersupersave" I like snappy.
mcbridematt has joined #aarch64-laptops
jglathe has quit [Remote host closed the connection]