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)
minecrell has quit [Remote host closed the connection]
minecrell has joined #aarch64-laptops
init has joined #aarch64-laptops
<HdkR> Does sc8280xp actually have the ability to only display 5120x4096? Or is someone lying to Xorg somewhere?
<steev> using xorg in 2023 smh
<HdkR> Sway doesn't support everything I need yet :)
<bamse> HdkR: what kind of display do you have?
<HdkR> This was just connected to my HDMI 2.0 capture card
<bamse> HdkR: it's not adequately representing the capabilities of the sc8280xp...
<HdkR> `Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 5120 x 4096`
<bamse> the cake is a lie
<bamse> also, we can't drive 5120x4096 at this time :(
<bamse> there's not enough juice in the pipe, as we currently configure the thing
<HdkR> Single panel sure, but what if I want to plug in both my 4k displays? :)
<HdkR> Which I've noticed that it can't go max speed on my 4k displays. I'm guessing HBR3 or DSC problems?
<bamse> HdkR: we can only drive 4k@30 today...
<bamse> HdkR: connecting two of those works fine...
<HdkR> What a shame, how am I suppose to drive my three 4k 144hz panels?
<bamse> there's ongoing work to support pooling the dpu resources in a way to achive the necessary throughput
<HdkR> :)
<bamse> good question...i don't know how far we'll reach with MST and these changes
<bamse> will certainly be interesting
<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
<bamse> @144 or just dual 4k?
<HdkR> Just one 4k panel just to see if GPU crashes happened more frequently with another display
<HdkR> That's what I was doing
<HdkR> Someone else probably going to be connecting a 4k 144hz panel and care about it :P
<HdkR> I at least was able to confirm that multi-monitor makes it easier to crash the GPU
<bamse> odd, except for the memory utilization i don't think there should be any relationship
<HdkR> Indeed, I just toggled vkcube between the two screens and it crashed almost immediately
<HdkR> Good stuff
<bamse> interesting
<HdkR> Userspace isn't quite fully ready
<HdkR> as far as I can tell
<HdkR> That'll get solved in time
<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
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
svarbanov has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
<jhovold> steev: heh, don't let incomplete tooling increase your leakage current! :)
svarbanov has joined #aarch64-laptops
frytaped[m] has quit []
fevv8[m] has quit [Quit: Idle for 30+ days]
malvi[m]1 has quit [Quit: Idle for 30+ days]
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
Dylanger[m] is now known as Dylanger
<jhovold> steev and anyone else using my wip branches, here's an update to 6.3-rc2:
<jhovold> Changes since rc1 include:
<jhovold> - new
<jhovold> - fix pops and clicks when starting and stopping audio
<jhovold> - keep shared bluetooth regulator always-on
<jhovold> - updated
<jhovold> - blutetooth v6
<jhovold> - smmu quirk v3
<jhovold> With srinik's latest ucm2 files you should also be able to use the DMICs in stereo.
init_x13s has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
init_x13s has quit [Remote host closed the connection]
matthias_bgg has joined #aarch64-laptops
<steev> oh very nice
<clover[m]> naicee
<steev> i'm guessing the popping was the mute/unmute in trigger?
svarbanov has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
<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?
<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
<steev> ah, dang
<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...
<bamse> steev: so better to land this with always-on and then someone with schematics can go back and drop that later
<steev> :)
<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
<steev> i was trying to figure out what they heck they are doing in there
<steev> because they have some nodes that just seem to lower power output or some such
<clover[m]> steev: are you concerned about battery drain with regulator being always-on?
<steev> not really
<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)
<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
<steev> i.... don't remember if i pushed mine out
<steev> it should though, against... sid?
<steev> you should be able to snag those 3 patches and drop them into debian/patches/ and so forth
<steev> or let me find my stuff and push it to salsa if i haven't
<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
<steev> there are still some glitches here and there, but overall yes
<steev> Man… the AirPods *really* want to stick to the thinkpad
<steev> I tell my phone to connect to them, and the thinkpad yanks them back
matthias_bgg has quit [Ping timeout: 480 seconds]
<clover[m]> Yeah, smooth gnome animations and whatnot.
<steev> eh, they were smooth for me even with llvmpipe
<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?
<steev> no, of the debian package
<steev> which will already exist because debian patches mesa
cmeerw[m] has joined #aarch64-laptops
<Nao[m]> and where would I find that
<steev> on salsa?
<steev> or just apt source mesa
<init> noob question, for steev or jhovold. Where do you guys all gets the voltage you end up setting in the dtb? Reverse engineering?
<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.
matthias_bgg has joined #aarch64-laptops
<init> but how to get the right one?
<steev> hope someone who has the actual answer chimes in during code review if it's wrong :D
<steev> like how jhovold has told me we need to regulator-always-on because the wifi also uses it
<steev> technically, i should know that, since it's on the same chip... but in practice, i forgot
<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...
<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
<steev> and then someone with access to the schematics gave me the info (lenovo said they could)
<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
miracolix has joined #aarch64-laptops
JoshuaAs- has quit [Ping timeout: 480 seconds]
JoshuaAshton has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
ema has quit [Quit: leaving]
ema has joined #aarch64-laptops
<macc24> hexdump01: have you tried kernels newer than 6.1 on krane?
<macc24> i'm getting this weird null pointer deref error in mtk_dsi_bind
hightower2 has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]