00:32 <harvestz[m]> I'm looking to install the Armbian image to the x13s, any tips on what I should do in the bios? Enable the beta linux option?

01:05 <steev> maybe #armbian over on libera? (though i believe they also have a matrix channel and their irc/matrix/discord are all bridged)

01:11 <harvestz[m]> I got it working, very slick!

01:12 <harvestz[m]> appreciate everyone working on this

01:14 <steev> oh nice

01:14 <steev> which version of the kernel do they have? (they mentioned me in their tweet about it)

02:02 <harvestz[m]> <steev> "which version of the kernel do..." <- 6.4 but I'll check for a more specific version tomorrow.

02:30 <harvestz[m]> <steev> "which version of the kernel do..." <- 6.4.3

02:31 <steev> okay, cool - i let them know the 6.4.7 push breaks audio and the changes needed based on what johan said is needed but i'm not sure if i posted it in the right area of their discord or not

16:41 <jlinton> Is there a public TODO for generic (not distro specific) x13s issues? Ex: It seems that the USB-C isn't negotiating PD voltages/etc correctly while in linux (vs the firmware or windows, where it will negotiate 9V using the supplied charger, but usually just leaves it at 5V in linux).

16:42 <jlinton> I applied some of the not yet upstream patches, to get the USB phy/speeds up, but none of that appears to have cleared the problem up either.

16:49 <clover[m]> i have something kinda like that https://github.com/ironrobin/archiso-x13s/wi#bluetoothki/Feature-Support but i didn't know abou tthe PD thing

16:50 <clover[m]> s/abou/about/, s/tthe/the/

17:09 <Jasper[m]1> I did have the same pd problem, but I think I also had it when it was off

17:15 <robclark> is pd for charging, or providing power? A couple times I saw that the x13s stopped charging while plugged in.. (but I haven't seen that in the last couple weeks or so)

17:17 <bamse> robclark: it would be for negotiating with the oter side who should provide power, and how much

17:18 <robclark> ok, so for power in both directions? So this could be related to the charging bug?

17:18 <bamse> we have ucsi_glink.c upstream, which does this on sm8450 and sm8550, but it's not enabled for sc8280xp

17:19 <bamse> robclark: that is plausible

17:19 <robclark> ahh

17:52 <clover[m]> https://www.phoronix.com/news/Qualcomm-Iris-Video-Linux

17:52 <clover[m]> Is this germane to the x13s?

17:53 <clover[m]> Also isn't iris already an intel/apple gpu lol

17:54 <bamse> and the rf module for wcn3660/wcn3680...

17:54 <HdkR> nack because of the bad overlapping name? Name it cornea or something? :P

17:55 <bamse> i much prefer "iris" over the good old "vidc"

17:57 <bamse> clover[m]: and no, x13s works with the current "venus" driver

17:57 <bamse> clover[m]: with some patches in flight...

18:00 <robclark> so, both venus and iris conflict with mesa driver names.. someone pls ask qcom to consult mesa dev's before naming a new hw block ;-)

18:01 <bamse> robclark: :)

18:02 <HdkR> "Mesa has a good sounding name for that. Lets use it."

18:02 <HdkR> oh no, not the bad timeline!

18:03 <clover[m]> 'snapdragon' is a great name though

18:03 <bamse> well, the "venus hardware" has been named iris for years now...

18:13 <steev> yavd-ng; yet another video decoder, next generation

18:13 <steev> ez

18:14 <bamse> vidc2

18:16 <steev> the best name i ever came up with for a dev board was "shortbus" because they kept taking features away from us and making the board stupid

18:17 <steev> CEO loved it because he thought it was talking about the size of the board

18:18 <bamse> love it

18:19 <steev> unsurprisingly, the board never made it out of development

18:38 <Bioxvirizm-x13s[m]> trashcan best name=)

18:59 <steev> those are the hostnames for my rpis

19:01 <Bioxvirizm-x13s[m]> =))))

19:03 <HdkR> Worked on a product that played on the codename which turned in to "Mistake". That also never shipped :P

19:18 <jlinton> robclark: The USB-C/PD for powering/charging the machine from the AC adapter. So, yes if the machine is drawing more than ~10W it probably won't be charging.

19:38 <_`[m]> wtf am I the only one who can't manage to build a bootable kernel around here 😢

19:39 <_`[m]> nixos is tedious af too lol go figure huh 😉

19:46 <jlinton> No, it took me a _long_ time to sync the fedora config with the defconfig that booted because everytime something went wrong I couldn't see what was wrong because the DT/vrm/clk/whatever was turning off the screen.

19:49 <konradybcio> dont even get me started about getting all the ubuntu's weirdness to run without distro config ;)

19:50 <konradybcio> at this point i should switch to a real distro but ever since ndec lent me a usb stick with an installer ive been too lazy..

20:16 <_`[m]> <jlinton> "No, it took me a _long_ time..." <- how you worked around that huh?

20:16 <_`[m]> <konradybcio> "at this point i should switch to..." <- I get that 😲

20:16 <_`[m]> I'm even considering running arch at this point haha

20:27 <clover[m]> got my modem working on my X13s, had to create my own symlink since what modemmanager ships with doesn't match what i have in lspci directly. but im getting bad speeds and low signal strength. 1.5 Mbps per fast.com

20:29 <clover[m]> oh its the same in Windows. maybe my apartment just has crap 5G speeds

20:37 <jlinton> Its still not 100% but I got a big honken arm server and I merged, built and booted 6.5 with bits of the working defconfig against the non working sections in the fedora Config reverting when it didn't boot. The reason I say its not quite there yet, is because its not just a single pass event because there are dependent config options, and I've got another entire pass or two left before its just bugs and QC drivers.

20:41 <jlinton> Things like "CONFIG_DEBUG_LIST" and "CONFIG_BUG_ON_DATA_CORRUPTION=y" ended up getting turned off because they failed to boot at some point, so i'm going back in and turning them on and trying to see if whatever was failing was transient or I can capture output with either the network or the rootfs mounted.

20:46 <ajhalaney[m]> fwiw jlinton i had booted from kernel-6.5.0-0.rc1.eb26cbb1a754.13.el127 in kernel-ark with the default aarch64 fedora config. You do need to manually at the interconnect driver(s) into the initramfs unless you are on rawhide (which has this https://src.fedoraproject.org/rpms/dracut/pull-request/41)

20:48 <ajhalaney[m]> I haven't found much time since then to poke at anything x13s related unfortunately, and I spent most of the time I wanted to dedicate to that realizing the interconnect drivers weren't included in my initramfs :P

20:49 <ajhalaney[m]> I also see that the grub issue I wanted to chase eventually has already been properly chased by you and qzed :)

21:47 <Jasper[m]1> Oh nice, FF 116 is out. Should mean v4l2-m2m hopefully.

22:11 <clover[m]> bumped mesa to 44.3 for gnome arch users. still carrying that meta-kms-better-handling-for-universal-planes patch...

22:16 <robclark> hmm, that would be a mesa release 21yrs in the future :-P

22:19 <jlinton> ajhalaney: well I have that kernel, and that dracut fix, and the grub fix, *ignore_unused, arm64.nopauth, and various other things and it doesn't boot completely by default. Granted, I'm booting off a USB disk, and I do have a working debug kernel config, with a couple other things compiled in at the moment, so its likely another dracut patch needed, etc. It feels like i'm finally closing in on a functional machine, but

22:19 <jlinton> i've also got some of the non-upstream patches applied now too.

22:20 <jlinton> Either way, hopefully in the next day or two I can understand what exactly needs to be tweaked/merged to get it functional.

22:20 <steev> i've heard a few people say usb booting doesn't work for them

22:21 <jlinton> Yah, the USB boot is likely mandatory for the default fedora workstation/etc install process for most people.

22:21 <steev> robclark: well he's a futuristic kinda guy ;) im pretty sure he meant mutter

22:21 <ajhalaney[m]> Sounds pretty identical to my setup except I was booting off pcie

22:21 <Jasper[m]1> Yep, for me it loads the kernel but doesn't find the rootfs. Replugging doed work

22:21 <Jasper[m]1> *does

22:22 <steev> i've seen some other usb patchsets on the mailing list, but i've just not had the free time lately to look at things

22:23 <steev> even now... 1 more person going on vacation so it's down to just 2 of us working on the team

22:25 <ajhalaney[m]> I've been told somewhere (can't find it but it's somewhere here) that when adsp remoteproc starts the USB loses power briefly, so that would complicate things

22:31 <jlinton> Yes? One of the problems is that something is starting late which appears to be resetting the USB after the rootfs is mounted and its been a bit of a mystery what it is.

22:33 <jlinton> At the moment though the working/noworking deltas are the same for the remoreproc config options.

22:38 <jlinton> I'm also getting iommu faults from the XHCI once or twice a day, which is fun too.

22:47 <ajhalaney[m]> iiuc pd-mapper (userspace) kicks off all the dsp related stuff, so maybe that will help you on your quest. wrt iommu faults that's one I don't think I've seen

22:50 <jlinton> I've got a bunch of the !upstream USB patches in my tree to fix the fact that it was only running the USB at USB2 speeds. So its possible I've shot myself in the foot with some of them too.