00:22 <agl> steev: Was there always patches necessary on 6.13.y for the x13s?

00:22 <steev> we will always need them if we want venus until qcom get off their asses and submit the firmware

00:22 <steev> you can run vanilla without it though

00:28 <agl> steev: excuse me for asking so ignorantly: what is venus?

00:35 <agl> steev: This is the first time I've heard this in connection with the x13s.

00:35 <steev> the hardware media encoder/decoder

00:36 <agl> Ah for the sound, or?

00:38 <abby> video

00:38 <agl> abby: OK

00:43 <anthony25> why can't the patches be upstreamed? the firmware are not in linux-firmware, but can't we refer to them in the device trees?

00:48 <steev> something something interconnects something power usage

01:00 <steev> agl: i pushed again, dropping the bore scheduler, it has makes the kernel test bots too cranky at me (and i'm not developing it so don't wanna deal with them)

01:11 <agl> steev: Does it need some time until there isn't "last week" for the setting time?

01:12 <steev> huh?

01:13 <agl> I mean the time where you have pushed the new kernel?

01:13 <steev> `lenovo-x13s-linux-6.13.y had recent pushes 14 minutes ago`

01:13 <steev> if you're looking at the actual commit, i *dropped* one, i didn't apply others

01:17 <agl> steev: OK, I get it once more ...

01:26 <agl> steev: the new zip-archive of 6.13.y is exactly 5727 Bytes smaler.

01:29 <robclark> steev, bamse, konradybcio: re: venus/iris fw vs power when driver doesn't probe.. what if we had zero length placeholder fw files in linux-firmware, which could be overridden with the actual fw copied from windows (or if vendor upstreams firmware).. then the driver just needs to realize it got a bogus fw and shut things down? Would that give us a path to enabling venus/iris by default?

01:39 <steev> that seems like a lot of steps to just say "if no firmware, shutdown" instead?

01:42 <robclark> problem is kernel needs a way to differentiate btwn "no fw" and "no fw yet, try again later"

01:56 <agl> Good Night, here in Europe is it now 2:56am o'clock ... I'am going now to bed ...

02:23 <steev> 5 fails and shut down? ideally without spamming the kernel logs

02:23 <konradybcio> robclark it wouldn't pass authentication

02:24 <konradybcio> So I'm guessing einval

02:24 <robclark> that is kinda the point.. or driver could just check length before trying to authenticate it

02:47 <xamboni> I recently purchased a Lenovo Yoga 7x. Tobhe's Ubuntu live CD boots out of the box which is very nice. Are there any resources to help get started building my own kernel for a snapdragon machine?

02:48 <konradybcio> robclark i think this is a bigger discussion.. we would certainly appreciate a mechanism that would probe venus and shut down its resources to allow for sync_state to complete

02:49 <robclark> I am ofc open to other ideas, but we need to do _something_

08:35 <icecream95> There seems to be a PSCI firmware bug (on x1e) where sometimes trying to enable CPUs gets ON_PENDING forever. (It seems to be deterministic based on the order of bringing up cores.)

08:38 <icecream95> This doesn't happen if CPUs are brought up at boot rather than setting maxcpus=1 and enabling them one-by-one later... *except* that a normal boot doesn't CPU_ON core 0, so the bug still occurs there.

08:42 <icecream95> (The qcom EL2 hypervisor doesn't hit this bug, so maybe it isn't actually turning off cores for CPU_OFF calls.)

08:48 <icecream95> Of course I am hitting this with my own hypervisor... which might be stable enough to boot Windows now, or at least would be if Windows didn't decide to reboot the system for some reason.

08:48 <icecream95> Hopefully it at least gets far enough to load the kernel debugger, I'll check that tomorrow

08:53 <icecream95> I am a bit worried that the "Firmware protection" setting in Windows can't be turned off (without it turning itself on again); it's unsurprising that Secure Launch can't be disabled, but might cause problems for me (unless I decide to implement nested virt?)

09:58 <kuruczgy> xamboni: Do you want to build it manually, or using a distro package? Manually it should be `make johan_defconfig` (if using Johan's branch, or a different defconfig if using a different one), and then something like `make -j12 Image dtbs modules`

09:58 <kuruczgy> For cross some extra flags would be needed, but I don't know them off the top of my head

10:08 <kuruczgy> icecream95: Cool. What's your boot chain? Are you booting your hypervisor using slbounce, which then loads the windows bootloader? Do you already have any code to share for the hypervisor?

11:13 <Treibholz> steev: Copying the venus firmware manually from the windows partion to /lib/firmware works for me, unfortunatelly it's not very stable (on 6.11.x), so I rmmod the module in "normal operation".

11:27 <albsen[m]> Treibholz: which OS did you install, and did you leave a windows partition or removed it completely?

11:30 <Treibholz> albsen[m]: I'm currently running Ubuntu 24.10 with 6.11.0-99-generivc from ubuntu concept ppa on the X13s. For now I kept the windows-partition (just shrinked it to ~100gb)

11:33 <albsen[m]> ok, got it. I'm using debian on my x13s, trying to figure out how to best setup my t14s now.

11:38 <Treibholz> albsen[m]: As I want to use it as my daily driver, I don't want to use trixie, yet. I'll wait until the the soft-freeze. (if I can endure Ubuntu that long...)

11:43 <exeat> I don't think I've ever had venus work without decode errors, though I've only tried mpv and ffplay and not (say) gstreamer

11:43 <Treibholz> And I must say, I picked the right point in time, to buy the X13s. Since January everything of "real" relevance to me works.

11:44 <exeat> I'd love for someone to point me to a video that decodes with no errors with e.g. "mpv --hwdec=v4l2m2m-copy" or "ffplay -vcodec <codec>_v4l2m2m" (or tell me that I'm doing it wrong)

11:45 <Treibholz> exeat: it works okeyish with mpv on the stream of German public television. But somehow firefox does not want to display GIFs then,,,

11:49 <Treibholz> exeat: but without it, mpv uses about the same amount of CPU, as on my T14gen3 (i7) with hw-acceleration.

11:51 <Treibholz> (but it get's hot and makes noise and the battery lasts max. 3h, so the X13s is the much better choice for me)

11:55 <Treibholz> also the T14gen3 is not really faster than the X13s - maybe for max. 10sec, then the temperature throttles the CPU.

11:56 <albsen[m]> Treibholz: I been using trixie and it's great. haven't had any issues and it's my main machine.

12:00 <Treibholz> albsen[m]: My younger self got burnt by rolling-release distributions too often. I normaly run Debian stable (with bpo and some personal backports), because I prefer to know what doesn't work, to finding out whats broken after a dist-upgrade. :-)

12:01 <Treibholz> albsen[m]: Ubuntu is experimental enough for me :-)

12:07 <Treibholz> albsen[m]: but I already prepared a small trixie-partition, to play around. Snap makes me crazy. But on the other hand, I don't know how to get a recent, stable firefox (not ESR, not nightly) on debian aarch64. And compiling firefox yourself is a PITA.

12:32 <exeat> Debian unstable works great IME, as long as you can cope with its step function (pre-release freeze, post-release flood every couple of years) and are prepared to deal with the occasional, well, instability

13:31 <albsen[m]> Treibholz: I'm on trixie so, that FF is recent, but you can always use nixos in debian, or mark trixie FF to be included in bookworm

13:40 <SpieringsAE> is there a way to make an i2c bus depend on a supply? Not just a device on the bus? Can't really find a property like that on any i2c bindings

13:40 <SpieringsAE> theres a 1v8 regulator ruining my life

13:46 <JensGlathe[m]> That i2c bus has a controller node somewhere...?

13:48 <SpieringsAE> yeah but I don't see a property for a supply on the i2c bus controller

13:48 <SpieringsAE> so it wont do anything with it I think

13:48 <\[m]> anyone by any chance has interest in trying to compile mROC and functionally testing ?

13:49 <JensGlathe[m]> maybe for the complete block ?

13:49 <JensGlathe[m]> or domain?

13:49 <Treibholz> albsen[m]: trixie also only provides firefox-esr, but the nix-idea is interesting...

13:50 <albsen[m]> yeah, been using nix on voidlinux too, its great to work around those odd 2 or 3 missing ones. let me check if I have esr ...

13:52 <albsen[m]> nope, dont think so, at least help/about doesnt show esr. (I recall it used to at some point)

13:58 <Treibholz> probably brew on linux could also be an option for those missing ones... But they don't support arm on linux (yet)

14:20 <anonymix007[m]> icecream95: can you somehow virtualize the environment for qcom hypervisor to work and log what it actually does to enable DSPs?

15:27 <robclark> maybe with nested virt if QC hyp doesn't check that it is running under a VM?

15:33 <JensGlathe[m]> which would be hilarious

15:49 <SpieringsAE> maz: fixed my i2c issue, the 1v8 ldo output to ground resistor was too high, so it didn't drop fast enough during a reboot (?) which left some jank in a level shifter or something which ruined the i2c bus

15:49 <SpieringsAE> that was one hell of a journey

19:42 <steev> Treibholz: you can enable sid for *just* firefox (just an option); but yeah, i see a lockup using anything gstreamer here and i have spent 0 time looking into it

19:43 <ppd[m]> I guess I should change my question: what's the audio situation on the t14s, surface romulus, or the hp omnibook? Does it have limitations?

19:44 <ppd[m]> I'm asking because I was going around comparing device trees and the slim 7x seems to be missing the audio-codec entry

19:47 <JensGlathe[m]> t14s is known to be working. I intend to duplicate this on the HP Omnibook. Still pending.

19:48 <ppd[m]> I assume you have the omni?

19:48 <JensGlathe[m]> yep

19:49 <ppd[m]> Ah, ok. What was the requirements for getting it working on the t14s? Just firmware, devicetree, and ucm stuff?

19:49 <ppd[m]> ALSA ucm*

19:50 <JensGlathe[m]> devicetree, adsp firmware, alsa UCM, additional WSA888x patches iirc.

19:51 <JensGlathe[m]> This one I guess https://lore.kernel.org/all/20241023124152.130706-1-krzysztof.kozlowski@linaro.org/