01:36 <HdkR> Does sc8280xp actually have the ability to only display 5120x4096? Or is someone lying to Xorg somewhere?

02:06 <steev> using xorg in 2023 smh

02:07 <HdkR> Sway doesn't support everything I need yet :)

02:24 <bamse> HdkR: what kind of display do you have?

02:27 <HdkR> This was just connected to my HDMI 2.0 capture card

02:28 <bamse> HdkR: it's not adequately representing the capabilities of the sc8280xp...

02:28 <HdkR> `Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 5120 x 4096`

02:28 <bamse> the cake is a lie

02:29 <bamse> also, we can't drive 5120x4096 at this time :(

02:29 <bamse> there's not enough juice in the pipe, as we currently configure the thing

02:29 <HdkR> Single panel sure, but what if I want to plug in both my 4k displays? :)

02:30 <HdkR> Which I've noticed that it can't go max speed on my 4k displays. I'm guessing HBR3 or DSC problems?

02:31 <bamse> HdkR: we can only drive 4k@30 today...

02:31 <bamse> HdkR: connecting two of those works fine...

02:31 <HdkR> What a shame, how am I suppose to drive my three 4k 144hz panels?

02:31 <bamse> there's ongoing work to support pooling the dpu resources in a way to achive the necessary throughput

02:32 <HdkR> :)

02:32 <bamse> good question...i don't know how far we'll reach with MST and these changes

02:32 <bamse> will certainly be interesting

02:34 <HdkR> I know at least one person that actually wants this, I just noticed it because it was annoying to arrange one panel below the other rather than side by side

02:35 <bamse> @144 or just dual 4k?

02:36 <HdkR> Just one 4k panel just to see if GPU crashes happened more frequently with another display

02:36 <HdkR> That's what I was doing

02:36 <HdkR> Someone else probably going to be connecting a 4k 144hz panel and care about it :P

02:37 <HdkR> I at least was able to confirm that multi-monitor makes it easier to crash the GPU

02:38 <bamse> odd, except for the memory utilization i don't think there should be any relationship

02:38 <HdkR> Indeed, I just toggled vkcube between the two screens and it crashed almost immediately

02:39 <HdkR> Good stuff

02:39 <bamse> interesting

02:40 <HdkR> Userspace isn't quite fully ready

02:40 <HdkR> as far as I can tell

02:48 <HdkR> That'll get solved in time

03:57 <steev> jhovold: btw, i went with bias-pull-down because the sc8280xp-tlmm bindings yaml didn't seem to know anything about bias-bus-hold and dtbs check would complain

08:30 <jhovold> steev: heh, don't let incomplete tooling increase your leakage current! :)

11:20 <jhovold> steev and anyone else using my wip branches, here's an update to 6.3-rc2:

11:20 <jhovold> https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.3-rc2

11:21 <jhovold> Changes since rc1 include:

11:21 <jhovold> - new

11:21 <jhovold> - fix pops and clicks when starting and stopping audio

11:21 <jhovold> - keep shared bluetooth regulator always-on

11:21 <jhovold> - updated

11:21 <jhovold> - blutetooth v6

11:21 <jhovold> - smmu quirk v3

11:22 <jhovold> With srinik's latest ucm2 files you should also be able to use the DMICs in stereo.

14:14 <steev> oh very nice

14:39 <clover[m]> naicee

14:39 <steev> i'm guessing the popping was the mute/unmute in trigger?

15:06 <steev> jhovold: should it really be always on though? can't we just (once it's in) specify that the wifi uses it and not always on?

15:27 <jhovold> steev: no, i'm afraid it needs to be always on for now. There's no driver support to descibe that resource fully at the moment

15:27 <steev> ah, dang

15:34 <bamse> steev: in addition to wifi there's a bunch of other users of s1c as well, so we'd need to capture those fully...

15:35 <bamse> steev: so better to land this with always-on and then someone with schematics can go back and drop that later

15:35 <steev> :)

15:36 <steev> jhovold: ill be honest... i don't remember wtf i was doing there with the regulators... i am pretty sure i had the documentation open in one, and something like the qcard dts open in another and comparing

15:37 <steev> i was trying to figure out what they heck they are doing in there

15:37 <steev> because they have some nodes that just seem to lower power output or some such

15:40 <clover[m]> steev: are you concerned about battery drain with regulator being always-on?

15:41 <steev> not really

15:41 <steev> i'm just not a fan of leaving a regulator on that doesn't *need* to be (but for now, we need it to, it seems)

15:43 <Nao[m]> I saw there was a Mesa fork for the Adreno 690 is there a way to build it for debian since it seems like its for Arch atm

15:44 <steev> i.... don't remember if i pushed mine out

15:44 <steev> it should though, against... sid?

15:44 <steev> you should be able to snag those 3 patches and drop them into debian/patches/ and so forth

15:45 <steev> or let me find my stuff and push it to salsa if i haven't

15:46 <Nao[m]> Would it enable hardware acceleration for the DE? as far as I understood all the graphics were handled by the CPU on the kernel from the linaro guide

15:48 <steev> there are still some glitches here and there, but overall yes

15:52 <steev> Man… the AirPods *really* want to stick to the thinkpad

15:52 <steev> I tell my phone to connect to them, and the thinkpad yanks them back

16:07 <clover[m]> Yeah, smooth gnome animations and whatnot.

16:10 <steev> eh, they were smooth for me even with llvmpipe

16:12 <Nao[m]> <steev> "you should be able to snag those..." <- I've never done that before, so make folders debian/patches in the root of the fs?

16:26 <steev> no, of the debian package

16:26 <steev> which will already exist because debian patches mesa

16:33 <Nao[m]> and where would I find that

16:33 <steev> on salsa?

16:33 <steev> or just apt source mesa

16:35 <init> noob question, for steev or jhovold. Where do you guys all gets the voltage you end up setting in the dtb? Reverse engineering?

16:36 <steev> for me, it was looking at what others did (if they did) if similar, or looking at the kernel output complaining about a voltage being wrong.

16:40 <init> but how to get the right one?

16:40 <steev> hope someone who has the actual answer chimes in during code review if it's wrong :D

16:41 <steev> like how jhovold has told me we need to regulator-always-on because the wifi also uses it

16:41 <steev> technically, i should know that, since it's on the same chip... but in practice, i forgot

16:43 <travmurav[m]> to get the right one, one has to know how the board is built (i.e. by having access to the schematic or otherwise knowing who are the consumers on that supply), sometimes it's possible to find how original software sets regulators up, sometimes it's possible to extract limits from the rpm firmware...

16:48 <steev> wrt bluetooth, i stumbled across a file in windows - "bsrc_bt.bin" in the bluetooth driver folder, and since i'm the curious type, i ran strings on it, and it ended up spitting out things like PMICVREGVOTE PPP_RESOURCE_ID_SMPS1_C

16:48 <steev> and then someone with access to the schematics gave me the info (lenovo said they could)

16:53 <steev> i am definitely not one to do things the right way from the start... i mostly stumble into the correct answer by pure luck

19:46 <macc24> hexdump01: have you tried kernels newer than 6.1 on krane?

19:48 <macc24> i'm getting this weird null pointer deref error in mtk_dsi_bind https://bpa.st/2LVTS