ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev> well, dang
<steev> yuzu says it can't use the gpu on the thinkpad :(
<HdkR> Why's that?
<HdkR> steev: Didn't install Vulkan correctly or something?
<steev> according to the logs, we're missing some vk extensions?
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #aarch64-laptops
<HdkR> Interesting
<HdkR> I'd expected the first three aren't terrible, but widelines is questionable
<steev> i'm only on mesa 23.1.0
<steev> and trying to switch it to opengl, it says we need opengl 4.6 and i do believe we only do 4.5?
<HdkR> Might work if you override the version. I think the main thing they want is the spirv extension there
<HdkR> Or if you're lucky they just check for extensions
<steev> doesn't matter though, even on my windows box... the xbox one elite controller doesn't quite work properly with totk
<clover[m]> You can get totk on windows?
<steev> with yuzu, yeah
<HdkR> It's emulation
<steev> i don't have the switch pro controller, and not gonna try to get joycons working
mcbridematt has joined #aarch64-laptops
<steev> qzed: i do see the efivars files in /sys/firmware/efi/efivars on the thinkpad (though i have to admit this is with 6.4.0-rc2 and pulling in the 1 patch that's needed from -next
<qzed> nice, thanks for testing!
<qzed> could you also do a quick check that reading works (e.g. via efibootmgr or efivar -n <some-var>)
<steev> haven't tested the c630 yet
<qzed> thanks, looks like that works
hightower3 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
<bamse> steev: what am i working on? suspend?
<steev> bamse: using less power?
<steev> the rsc votes? i think it was
<bamse> ahh, well...whenever i find some time...mani_s and abelvesa are spending more time on it
<steev> :) i was just answering clover[m] :)
<steev> the only thing i *really* wish qualcomm would give us is.... firmware that does monitor mode again
<steev> That should be *i* not *really*
<bamse> sounds useful
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> for kali needs, it is :)
<steev> otoh, i do have a few boxes of wifi devices, so it's not the end of the world
<bamse> steev: have you talked to kalle about it?
<steev> i have not, didn't know that was a thing that was allowed
<steev> if i'm being honest, i figured it was a thing because.... cal.....something do modified firmware for sale
<steev> Candela
hightower4 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
<clover[m]> what is monitor mode?
<steev> Monitor mode: Sniffing the packets in the air without connecting (associating) with any access point.
<steev> the annoying thing is, it *reports* it can do monitor mode
<steev> software interface modes (can always be added): * monitor
<steev> sudo iw <interface> set monitor none *should* work, however, we get -95, which means... dun dun dun, not supported
iivanov has joined #aarch64-laptops
<HdkR> It's a very useful mode that most firmwares lock down
<clover[m]> If gpu works for yuzu do you think it would be able to handle a game like totk?
<clover[m]> I mean is the a690 strong enough?
<steev> Should be
<quinine> I haven't tried it, but I know that yuzu totk on steam deck doesn't perform as well as switch.
jhovold has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
kitsune-tsuki has quit [Ping timeout: 480 seconds]
Xyaon has joined #aarch64-laptops
Xyaon has quit [Remote host closed the connection]
Xyaon has joined #aarch64-laptops
<Xyaon> Hi! What's the current state of c630 development?
rmsilva_ is now known as rmsilva
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
kitsune-tsuki has joined #aarch64-laptops
agl7-x13s has joined #aarch64-laptops
_xav_ has quit [Ping timeout: 480 seconds]
<Xyaon> What is the most functional kernel for the c630? Version 5.11 by aarch64-laptops works fine, but I'm having gpu issues with 5.15. I get the same issues with steev's 6.3.2 in addition with wifi and usb ethernet adapters not working. Are those things still under development or am I doing something wrong?
xroumegue has joined #aarch64-laptops
<ardb> xyaon: i've been using 6.0 for a while now, but upgrading has been painful so i try to avoid it
laine has joined #aarch64-laptops
<bryanodonoghue> anybody else see ath11k_pci "HTC Rx: insufficient length, got x, expected y" ?
<bryanodonoghue> on x13s ?
<bryanodonoghue> on steev's lenovo-x13s-linux-6.4.y as @ 11 days ago
<steev> i see that occasionally here
hightower4 has quit [Ping timeout: 480 seconds]
svarbanov has joined #aarch64-laptops
<bamse> xyaon: i'm running v6.4-rc1 + battery-patch on my c630, seems to work well
<Xyaon> I figured out what I was doing wrong, the firmware files were missing from my initramfs
<bamse> danielt: any luck figuring out why hid_sensor_hub is kicking the keyboard on c630?
<Xyaon> has anyone got wwan working on c630?
<danielt> bamse: I have to admit I've rather fallen behind on kernels w.r.t. C630. Haven't actually opened it in a long time...
<bamse> danielt: you should ;)
<bamse> danielt: i'm always on my x13s these it would have been nice to fix those last few c630 pieces and "leave it" in a good state
<steev> xyaon: you need to throw the ipa firmware into your initramfs, or, reprobe the driver, it doesn't seem to do any sort of retry if it doesn't find the firmware when it first probes
<bamse> steev: isn't ipa a module? or it's being inserted into the ramdisk as well?
<steev> it should be a module, i'm not sure of their setup, i just remember here that i had that issue here, so i'm assuming the ipa module gets thrown into the initramfs for reasons
<steev> steev@limitless:~$ lsinitramfs /boot/initrd.img-6.3.3| grep ipa
<steev> usr/lib/firmware/ipa_fws.mdt
<steev> usr/lib/modules/6.3.3/kernel/drivers/net/ipa
<steev> usr/lib/modules/6.3.3/kernel/drivers/net/ipa/ipa.ko
<bamse> steev: ipa, venus and remoteproc all has the problem that firmware needs to be in the same place as the module...
<bamse> steev: so far for me though, none of them are picked up for the ramdisk...which saves me from having to stuff the firmware in there as well
<steev> i just have an initramfs hook that tosses the ipa fw into it, it's only 33K in size
<bamse> i don't know how to deal with this problem...we don't want to MODULE_FIRMWARE(), because that will just give us a bunch of unused firmware files in the ramdisk...
<bamse> right, but that's a manual thing you've set up
<steev> can we not tell it to probe defer if the firmware isn't found?
<steev> or do we need MODULE_FIRMARE to do that
<bamse> it will probably work...given that there are other drivers that are going to probe once the rootfs is in place...but it's a hack
<bamse> and we don't want MODULE_FIRMWARE, becase /lib/firmware/qcom is/will be hundreds of MB
<bamse> last time we tried to come up with a solution Linus answered the tune that wrote about it...
<steev> yeah
<bamse> so i've "ignored" the problem for a while now
<steev> a number of people link that to me and ask if i've ever gotten it, and i say... no, i'm not good enough to get that kinda reply
<steev> so, i do get my rmnet_ipa0, but, i don't recall if i've tried to actually connect
<Xyaon> I did that and it even shows up as a network interface, but ModemManager says it is not supported by any plugin
<steev> what distro are you using?
<steev> and what version of modemmanager
<Xyaon> arch
<steev> oh, i'll let bamse talk, he's the arch guy that would know what to do there
<Xyaon> i'm kinda new to IRC, do you just type name+colon to tag people?
<steev> pretty much, yeah
<bamse> i don't remember if we have a PKGBUILD for the arm flavor...but last time i looked at it, causes the problem
<steev> that does seem like it would cause issues
<bamse> xyaon: so take above PKGBUILD, just drop the line that disabled the qcom_soc plugin and makepkg -Ais that and you should be good
<Xyaon> that is quite straightforward
<bamse> xyaon: and then do what i should have done a long time ago and contribute that ;)
<Xyaon> thanks :)
<bamse> you're welcome
<steev> Time to do kernel dev in vr
<steev> But also 2K for an 865??
<steev> AR, not VR
<bamse> very cool concept though
<HdkR> "the headset, which delivers 1080p resolution per eye, at 72Hz" eesh, barfy
<bamse> that's like 2160p!!!11!1!1
<HdkR> lol
hightower2 has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
<kitsune-tsuki> bamse: like, 1/2 of a 2160p. True 2160p is 3840x2160, 2x 1080p is something like 1920x2160
<bamse> kitsune-tsuki: does AR use the typical aspect ratios?
<bamse> kitsune-tsuki: and i was just joking
<HdkR> It's a joke I understand well because of the terrible marketing of those 4k/5k ultrawides and the pimax "8k"
* bamse would like to have one of those 10k wide-screen panels that are making their way into cars these days
<gwolf> bamse: Oh, have you been out already? They call them "windshields". Resolution is stunning!
<bamse> gwolf: i'm lost when it comes to these new technologies...
svarbanov has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
<clover[m]> steev: do you want these WWAN configs?
<steev> i can enable them, sure :)
<konradybcio> not sure if QCOM_BAM_DMUX is necessary
<clover[m]> ok i left a comment to them
<steev> at some point... i'm planning to fold back in support for the c630 and the flex5g, since i'd like to use one kernel across all the qualcomm devices i have
<steev> so i'm fine with having it
<steev> it's a module anyway
<clover[m]> linux-qcom hell yeah
<clover[m]> HdkR: GPU won't work for slack in FEXBash:
<clover[m]> any ideas?
<HdkR> Apparently the render process is just crashing here
<steev> i just run slack in the browser
<HdkR> I'd also recommend that
<HdkR> Anything that is just an embedded browser is going to be a pain
<HdkR> Like Steam
<robclark> so.. gpu-process sandbox seccomp rules are pretty arch specific.. I wouldn't be completely surprised that that falls completely over if it tries to use x86 seccomp rules on arm64
<robclark> actually, I'd be a lot more surprised if it did work, tbh
<HdkR> That's what --no-sandbox is for, since FEX doesn't support seccomp and we report to the application that we don't support it
<robclark> I guess that would take fex doing some pretty heroic seccomp re-writing
<robclark> ahh
<robclark> but yeah, disable sandbox if you really need to (although not sure why you'd need to run a glorified web app under fexemu)
<steev> oh nice, the orientation switching is in next now :)
<clover[m]> one less patch then? :)
<kitsune-tsuki> I've violated warranty only to get `gcc_ufs_phy_axi_clk status stuck at 'off'` from the kernel log
<kitsune-tsuki> how and why UFS initialization breaks other clocks and breaks firmware-configured mipi-dsi is above me
<bamse> robclark: have you ever had arm_smmu_get_by_fwnode() return NULL and thereby arm_smmu_probe_device() oops? i got this when probing adreno on my sc8280xp...but it doesn't show up again after a reboot, so seems to be some race...
<bamse> kitsune-tsuki: do you boot with clk_ignore_unused pd_ignore_unused?
<robclark> bamse: hmm, no, haven't seen that..
<kitsune-tsuki> bamse: ofc
<bamse> kitsune-tsuki: you'd be surprised how many times that has solved such issues :(
<bamse> kitsune-tsuki: hopefully we'll figure out way out of that soon though...
<bamse> robclark: trying to make sense of the code, but only thing that makes sense is if adreno_smmu is racing with gpu probing...
<robclark> bamse: maybe the dev_get_drvdata() part returns NULL, ie. a race between probing smmu and device that uses it? Seems like that should be an -EPROBE_DEFER situation?
<bamse> robclark: right, smmu does iommu_device_register() right before setting drvdata...
<bamse> robclark: but i didn't think the two drivers would probe in parallel(?)
<konradybcio> kitsune-tsuki: did you try clk_ignore_unused pd_ignore_unused in your cmdline?
<kitsune-tsuki> konradybcio: yes
<bamse> robclark: anyway, it happened only low prio for now ;)
<bamse> robclark: seems valid to return EPROBE_DEFER from that though...
<konradybcio> kitsune-tsuki: you're essentially the first one to try ufs on 7180.. try cross-referencing some downstream kernel
<kitsune-tsuki> problem #1: sc7180 lacks any UFS definition in dtsi
<konradybcio> kitsune-tsuki: that's definitely a problem!
<kitsune-tsuki> problem #2: new (linux 6.4) sm7150 ufs_phy and sdm845 ufs phy blow up spectacularly (screen off)
<kitsune-tsuki> problem #3: any other com phy i've found in dtrees just spews errors
<kitsune-tsuki> problem #4: qcom downstream is really, really different from mainline
<konradybcio> you tell me ;)
<kitsune-tsuki> but clocks and registers values are same, thank goddess
<kitsune-tsuki> but that doesn't exactly helps when they are the same as in mainline
<kitsune-tsuki> which doesnt work
<konradybcio> did you confirm that with debugcc?
<konradybcio> linux only shows you what the thinks the state is
<kitsune-tsuki> errr
<kitsune-tsuki> i'm talking about values in dts and dtsi
<kitsune-tsuki> not about what is in hardware registers
<kitsune-tsuki> and I also have decompiled acpi table
<kitsune-tsuki> said acpi table is enough for windows installer to recognize and use ufs
<kitsune-tsuki> which is hilarious because said acpi table is _not_ enough for that installer to recognize keyboard and touchpad
<Libre____> hey I haven't read scrollback and I imagine you get this question all the time, but is X13s usable as a daily driver? How much time would it take to get to a fedora arm64 desktop?
<Libre____> my x86 thinkpad is starting to show early warning signs of failure...
<clover[m]> i haven't heard of anyone getting fedora working, but here is a feature support page:
<clover[m]> distros with existing support (that i know of) are: kali, ubuntu, arch
<Libre____> cool, cool
rfs613- is now known as rfs613
<Libre____> $650+tax does almost seem worth it to test, but that's ANSI kbd
<Libre____> ohwell, thanks for the pointers clover[m] :)
<konradybcio> $650? Thrice that in EU.. :P
<Libre____> this was on ebay
<Libre____> seems to be almost vaporware in EU where I am
kitsune-tsuki has quit [Ping timeout: 480 seconds]
<clover[m]> Another happy customer
<steev> "But since this SoC only supported since 6.0+ and even still not in mainline," ????
<steev> also, to say kali supports it is kinda generous... you gotta "upgrade" it to kali from the debian install, currently
rfs613- has joined #aarch64-laptops