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
baozich has joined #aarch64-laptops
Mathew has joined #aarch64-laptops
mcbridematt has quit [Remote host closed the connection]
baozich1 has joined #aarch64-laptops
baozich has quit [Ping timeout: 480 seconds]
baozich1 is now known as baozich
mcbridematt has joined #aarch64-laptops
baozich has quit [Read error: Connection reset by peer]
baozich has joined #aarch64-laptops
Mathew has quit [Ping timeout: 480 seconds]
Mathew has joined #aarch64-laptops
mcbridematt has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
Mathew has quit [Quit: Leaving]
jglathe has joined #aarch64-laptops
martiert_work has quit [Remote host closed the connection]
martin has joined #aarch64-laptops
martin is now known as Guest13815
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
<jhovold>
jglathe: you no longer need the iommu options as the underlying issue has been fixed in mainline and stable, and you can the drop the aspm one with 6.7
<jglathe>
good news
<jhovold>
craftyguy: what distro are you on? just curious to find out which do not have MM pull in the fcc-unlock deps
<jglathe>
so only arm64.nopauth efi=noruntime pd_ignore_unused clk_ignore_unused are left
<jhovold>
right
<jhovold>
Jasper[m]: communication isn't really the problem, we just have no leverage over how Lenovo/Qualcomm use their resources
<jhovold>
they tried fixing the nopauth issue but it regressed windows, i was happy to hear they did not just give up directly after that
<steev>
he's using nixos
<jhovold>
ah, ok, so only nixos so far is having issues with qmicli not being installed? or maybe debian too
<travmurav[m]>
steev: you meancraftyguy?
<steev>
yeah
<jglathe>
will boot with these on volterra next time. Trying to distill a defconfig that is minimized for x13s and volterra.
<steev>
at least, i thought he mentioned it before
<travmurav[m]>
steev: jhovold: I'd say craftyguy being a full-time pmOS maintainer uses pmOS/Alpine :P
<steev>
oh no, that was martiert
<jhovold>
heh, ok, thanks
<steev>
i won't hold it against him
<steev>
surprised pmOS wouldn't pull in all the MM deps
<steev>
of all the distros that would have working wwan stuff, i'd expect it to be pmOS
<travmurav[m]>
I think we don't have anything for MM downstream so it would be in Alpine
<travmurav[m]>
also there is no need for fcc-unlock on mobile chipsets :P
<travmurav[m]>
but given it's Alpine, I'd not be surprised it's intentional MM doesn't depend on qmi-utils
<jhovold>
since you can't use the modem without it, I'd say it does
<jhovold>
someone could at least patch the *MM* fcc-unlock script so that gives some reasonable feedback to user about what is missing, instead of having MM go into some weird loop on startup
<travmurav[m]>
if it's wrt "no need on mobile chipsets", then I meant mobile as in "smartphone"
<travmurav[m]>
but yeah, stuff communicating that deps are missing would be good thing do do :D
<jhovold>
ah, sorry, misread your meesage about "MM doesn't depend on qmi-utils"
<travmurav[m]>
ah
<travmurav[m]>
well I stated a fact that in Alpine packaging it does not as of now
<jhovold>
that seemed to be what the MM fcc-unlock documentation says, though
<jhovold>
right, i got that on a re-read
krei-se- has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
<steev>
isn't it also something newer though? it used to be that everything shipped with unlocks enabled
krei-se- has quit [Read error: Connection reset by peer]
<jhovold>
you mean as in the distro haven't caught up with that this is now a strict dependency?
<steev>
no, i mean that they used to ship with the fcc-unlock stuff being unlocked, and it changed in 1.18.4 to not being
krei-se has joined #aarch64-laptops
<jhovold>
yes, it needs be enabled manually now, but the script still depends on qmicli, just as it did before that change
<steev>
ah
<steev>
i see what you're saying
<martiert>
it does seem like the sane default would be for the distros to pull inn qmicli and mbimcli as dependencies to ModemManager. Might not always be needed, but according to the MM docs it looks like they are always needed if you need to unlock something
<jhovold>
yeah, i'm inclined to call this a debian bug
<jhovold>
"The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality."
<jhovold>
it may not be needed for all modems, but when it's needed, it does provide a "significant amount of functionality"
krei-se has quit [Ping timeout: 480 seconds]
<jglathe>
nice way to put it
push_ has quit [Ping timeout: 480 seconds]
<steev>
yeah, it probably should get promoted to depends, though the vast majority of users are going to get recommended packages installed by default
krei-se has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<jhovold>
ok, if that's the debian default, then perhaps this is mostly a nixos/pmos bug then
iivanov has quit [Quit: Leaving...]
<martiert>
I'm going to make a patch for nixos at least. Basically going to add that it is pulled inn if we add anything to the `/etc/ModemManager/fcc-unlock.d` directory
<craftyguy>
jhovold: ya it's Alpine. TIL that the qmicli app is packaged separately than libqmi stuff, and MM only depends on libqmi
* travmurav[m]
mumbles something about craftyguy approving his mr fixing a fallout from that change back then
<craftyguy>
yeah, ok "today I relearned/remembered" then :P
hightower3 has quit [Ping timeout: 480 seconds]
Caterpillar has joined #aarch64-laptops
baozich has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
jglathe_ has quit [Remote host closed the connection]
jglathe_ has joined #aarch64-laptops
baozich has joined #aarch64-laptops
baozich has quit [Ping timeout: 480 seconds]
push has joined #aarch64-laptops
vkoul| has joined #aarch64-laptops
<steev>
lol
<steev>
i know exactly how that is
<steev>
like going through jglathe's commits for the flex5g and being like... why the hell is that kernel patch attributed to me??? oh.. because i wrote it
<ema>
with that change, linux 6.7 supports efi variables on the x13s :-)
<steev>
oh nice
<steev>
that reminds me that i should test the debian stuff on the c630. i already know that QCOM_IPA isn't enabled
<Jasper[m]>
<ema> "FYI I opened a merge request..." <- Is this already upstream or not?
<Jasper[m]>
Or is it gonna be Debian only until it is?
<jhovold>
Jasper[m]: it's all upstream, ema is just enabling a kernel option in a distro config
<Jasper[m]>
Ahhhh I see
<steev>
the debian kernel includes none of jhovold's WIP or my WIP+more-experimental stuff
<steev>
bryanodonoghue: btw, i see this in dmesg, is something not quite right here? i2c-qcom-cci ac4c000.cci: Found 19200000 cci clk rate while 37500000 was expected
<nerdboy>
i think i got one of those... distro cfg with missing efi bits
<steev>
the laptop_defconfig doesn't do efi bits because grub can't yet handle an efi binary, at least with what is in debian testing
<steev>
and it bites me every time i go to try pmOS c630 kernel stuff
<nerdboy>
i meant my own distro cfg, not anything in the wip branches
<nerdboy>
also i plucked a couple of bls/devicetree patches for my grub
<nerdboy>
*from the crap-ton of rh/fedora patches
jglathe_ has quit [Remote host closed the connection]
jglathe_ has joined #aarch64-laptops
<jglathe>
fkex5g? I commit for volterra, most of the time
<jglathe>
or is it the same M/B?
<craftyguy>
finally got mobile data going on my x13s, it was just missing apps required by the unlock script, heh.
<craftyguy>
sometimes Alpine Linux optimizes for install size a biiiit too much ;)
<steev>
erm, maybe i'm confusing, there are a lot of j names
<steev>
probably meant jenneron[m] and the flex/yoga5g
<jenneron[m]>
steev: have you manged to get bluetooth to work on lenovo flex/yoga 5g?
<steev>
yes
<jenneron[m]>
oh, hi
<jenneron[m]>
steev: any patches? could you open a MR to the same branch?
<jenneron[m]>
i will then rebase it all on 6.7 stable
<steev>
you should just have to set an address?
<steev>
if not... it's the capabilities being missing
<jenneron[m]>
huh
<jenneron[m]>
why does it work on 6.1.69 then
<steev>
oh
<steev>
that i'm not sure. in fact, the more i look at the bluetooth driver the more i scratch my head and wonder what the hell things actually are
<jenneron[m]>
funny
<steev>
not even joking :(
<jenneron[m]>
i'm also wondering if there is a good way to avoid discharging laptop to 0, so i don't have to open my device anymore
<steev>
like, we can do LE, even though LE isn't tagged as a capability, so what the hell is the point of the capability
<steev>
which, the endianness patch... i'm not sure where we're at.
<jenneron[m]>
ok, thanks
<jglathe>
I know this might be an odd approach, but how about setting local-bd-address in the dts and change it if desired later? This way the bt controller comes up without additional userspace hacks, at least
<steev>
because then every device comes with the same address
<jenneron[m]>
userspace service should be fine though
<jenneron[m]>
i've just realized i can depend on bootmac on lenovo flex/yoga 5g to fix bluetooth in pmOS
<jglathe>
using it here, but with additional proposed pre-set address to ensure the IF is up
<jglathe>
@craftyguy says it's already in use by pmOS
<jenneron[m]>
i mean lenovo flex/yoga 5g, not x13s
jhovold has quit [Ping timeout: 480 seconds]
<craftyguy>
bootmac has to be enabled per-device in pmOS, it's not enabled by default (i.e. devices that need it should have it enabled in their packaged pmOS config)
<craftyguy>
jenneron[m]: nice :)
<craftyguy>
ya I started to write a janky bootmac for the x13s, then discovered someone had already done it, and installing it fixed BT :P
<steev>
some day we will learn where to read the address from and all will be well
<steev>
jenneron[m]: so then it was just not having the mac addr in newer than 6.1?
<jenneron[m]>
i don't know, haven't tested yet
<jenneron[m]>
it's my main laptop, so it's annoying to switch kernel on it
<steev>
ah, sorry, thought you had based on the conversation
<jenneron[m]>
but i'm going to do it soon
<steev>
ah, for me it's just flipping entries in grub
<jenneron[m]>
well, i don't have a recent kernel with working UFS built yet
<jenneron[m]>
will do later
jglathe_ has quit [Remote host closed the connection]
jglathe_ has joined #aarch64-laptops
<steev>
oh, right, we haven't figured out why it doesn't work for you; perhaps you should try the rest of those patches, but i *think* we added them previously in a pull request. i've slept since i opened it so i don't remember