06:11 <macc24> @hogliux: you'll need to run mprime for far longer to be sure cpu cores are rock solid

06:11 <macc24> i usually left it overnight when testing my undervolts

07:13 <SpieringsAE> _merk: If you use my kernel/dtb the lid switch definetly works, it will turn off the screen at least when it is shut, I don't know a lot about suspend and such but that is a different thing, the lid switch definetly works

08:46 <dunc4n> <SpieringsAE> "_merk: If you use my kernel/..." <- does it turn off the screen forcefully? is it controlled by hardware?

08:51 <SpieringsAE> I think the screen stayed on before I added the lid switch but I'm not sure now, but I think it gets turned off by software

08:52 <dunc4n> that's the usual way, got curious

08:53 <dunc4n> gah, still no 6.13 compat for ZFS, can't give johans kernel a spin yet

08:56 <macc24> dunc4nn: the screen gets shut off by the operating system

10:08 <JensGlathe[m]> Thinkbook 16 G7 just landed here. 👨‍🏭 later

10:09 <_merk> JensGlathe[m]: yeh bebe!!!!

10:09 <_merk> i bm!

10:09 <JensGlathe[m]> sorta yes

10:09 <_merk> i love beamers

10:10 <_merk> how do i check when systemd resumed?

10:10 <_merk> i opened the lid and it appeared to be on already but i'm not certain maybe it just resumed instantly

10:10 <macc24> dmesg

10:11 <_merk> that'll tell me time since boot right

10:11 <_merk> what about real time?

10:12 <JensGlathe[m]> looks like this, dmesg time stops for the suspend https://pastebin.com/wMMWjqFc

10:12 <_merk> thx

10:13 <_merk> hmm it only seems to have lasted 13 seconds...

10:14 <_merk> i'll have to talk to rzster about how i can make this happen with acpid instead of systemd

13:34 <JensGlathe[m]> is there support for the Purwa SoC? This would be x1p42100, X1-45 GPU

13:38 <travmurav[m]> iirc last time someone tried it here it didn't boot at all

13:49 <tobhe_> someone managed to boot the acer swift go with X1P64100

13:49 <tobhe_> I think they just started from the t14s dtb

13:51 <JensGlathe[m]> well I guess I'll find out, since the Thinkbook 16 G7 has x1p42100

13:51 <tobhe_> oh but that is not purwa :)

13:51 <JensGlathe[m]> its not?

13:53 <robclark> if it is 10 core, it is hamoa.. if it is 8 (or less?) it is purwa.. re: purwa, konradybcio advised to hang tight so I guess something is on the way

13:53 <JensGlathe[m]> well then I'm hanging tight (or something)

13:56 <JensGlathe[m]> There are Vivobook S15 with this SoC now, too

14:06 <_merk> SpieringsAE: yes i'm experiencing lid shut screen off, i receive the acpi event close and open on lid

14:06 <_merk> and when i suspend with systemd and then hit a key i get button/ip

14:06 <_merk> up*

14:06 <_merk> but the kernel seems to be running

14:07 <TheBITLINK[m]> suspend is literally broken on the vivobook, no idea why exactly though

15:19 <SpieringsAE> I always turn off my laptop when I don't use it so I don't really notice it

17:50 <kuruczgy[m]> robclark: here is the gpu devcoredump ^

17:50 <kuruczgy[m]> (gist does not accept binary files so matrix seemed the easiest...)

18:27 <macc24> (i think gist does do that)

18:33 <robclark> kuruczgy[m]: I can't really tell from that where it is crashing, but CP_IB2_BASE doesn't really make sense (ie pointing to some cmdstream that we didn't capture).. but if you can reproduce it easily then you could try with FD_MESA_DEBUG=noubwc and FD_MESA_DEBUG=nolrz to see if either of those prevent the gpu hangs

18:39 <kuruczgy[m]> robclark: Okay, will try those, though I am not sure if steam passes env variables into its container environment.

18:39 <kuruczgy[m]> Also I should mention that this is mesa compiled for x86 (in fact it might be i686, not sure if Portal 2 is 32 or 64 bit), running through fex-emu, so it's not inconceivable that some weirdness is getting introduced by this.

18:44 <Jasper[m]> iirc portal 2 is still i686 ye

18:44 <macc24> i thought mesa was thunked?

18:46 <kuruczgy[m]> You have to do some extra setup to enable thunking which I haven't done yet.

19:04 <kuruczgy[m]> robclark: nope, neither helps, so far I can reproduce the crash every time. (I confirmed via `/proc/<pid>/environ` that Steam does indeed pass them to the game.)

19:05 <robclark> hmm, I wonder if I can install asahi steam rpm on fedora

19:10 <farchord> Good afternoon! How close are we to having working sound?

19:11 <farchord> Sorry if it's asked alot, came back from a 9 days cruise lol

19:14 <steev> working sound where? came back from lunch and lost track of everyone's machines :P (but really, if it has only been 9 days...)

19:29 <clover[m]> i got fired today, well company restructuring or whatever. :( if anyone knows devops openings let me know

19:30 <Jasper[m]> Sorry to hear that @clover. End Years are unfun

19:42 <clover[m]> first time unemployed in 8 years, should be interesting change of pace :)

19:43 <clover[m]> im considering starting my own business and trying consulting, if i can figure out how that works

19:43 <macc24> clover: where are you located?

19:43 <clover[m]> Texas, USA

19:50 <farchord> steev: well I see what you mean. But things move so fast in this channel XD

20:39 <kuruczgy[m]> robclark: What's exactly the dx12 situation? You said that some kernel bits are still missing. I have Witcher 3 running (~15 fps at half res low graphics, so not the best), and based on the the path of the binary it's the dx12 version. Could it be using some slower software emulation for the missing parts? (It's Steam's stock Proton, so I don't know what they have in there exactly.)

20:41 <macc24> kuruczgy @kuruczgy:matrix.org: isn't vkd3d supposed to do the dx12 work?

20:42 <kuruczgy[m]> macc24: yeah, but Rob said yesterday that "wip for vkd3d dx12 support.. kernel part might be ready for v6.14 or v6.15 and userspace in same timeframe"

20:42 <robclark> kuruczgy[m]: I'm not entirely sure what proton does if it doesn't see sparse support... maybe cwabbott knows. Maybe the game falls back to dx11?

20:46 <HdkR> It still supports D3D12 but at a lower feature level

20:46 <HdkR> FL 11.1 which the game supports using I believe

20:47 <macc24> dx12 "11.1" feature level aka "dx11"?

20:47 <HdkR> yes, but with the D3D12 API in front of it

20:47 <robclark> ahh, ok

20:48 <HdkR> A bunch of D3D12 games just rage quit if you don't report FL 12.0, but some have a nice fallback

20:50 <HdkR> Sparse will be a big boon towards testing a bunch of D3D12 games. I currently just rely on my radeon setup for those

20:51 <kuruczgy[m]> (In particular Witcher 3 was only ported post-hoc from dx11 to dx12 with some compatibility layer, so it probably doesn't need any features that weren't in dx11.)

20:52 <robclark> HdkR: https://gitlab.freedesktop.org/drm/msm/-/merge_requests/144 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533 if you want to try it out .. I'm running the kernel side on my 7x daily driver at this point

20:54 <kuruczgy[m]> robclark: is the kernel side already in Johan's branches (or if not can you please also link that?) Is sparse resource support the only thing missing for dx12?

20:54 <HdkR> I haven't updated my kernel in months and months. So maybe when I get back to using my Yoga 7x I can pick it up

20:55 <robclark> not in Johan's branch yet, and not quite ready for that yet

20:56 <robclark> and I think it is the main thing remaining .. the userspace half of it is also still a bit WIP so not really interesting unless you are building your own mesa as well

21:07 <cwabbott> sparse support on the laptop GPU is unfortunately a ways away because vkd3d-proton likes putting MUTABLE_FORMAT_BIT on images but we can't support that with sparse

21:07 <cwabbott> I would tell them to go fix it, but what they're doing is actually allowed by the spec and qualcomm just didn't notice that they can't implement it, so it's a giant mess

21:22 <yoyoquake[m]> Hi guys; is it the right place to talk about qcom x1p42100 arch and the fact that I'm desperately looking for a valid dts file to have a booting kernel https://bugs.launchpad.net/ubuntu-concept/+bug/2091365

21:25 <robclark> support for x1p42 in general has not been posted yet, but afaiu someone is working on it

21:27 <tobhe_> see https://oftc.irclog.whitequark.org/aarch64-laptops/2024-12-10#1733831527-1733831762;

21:32 <yoyoquake[m]> got it; so wait & see

21:38 <yoyoquake[m]> nevertheless I wonder what is the good method to work on a DTS for such a new hardware. without the soc spec, it seems to be a very long guess work

21:50 <Sukiru[m]> I'm also keeping an eye on this ^

22:03 <JensGlathe[m]> <yoyoquake[m]> "nevertheless I wonder what is..." <- You can start by comparing the dsdt of it against a known one. If you get hold of a BIOS update, there‘s also fdt‘s in it for comparison. Purwa and Hamoa seem to be pin compatible (which would make a lot of sense). I will post the ACPI tables of the T16 this weekend.

22:03 <JensGlathe[m]> The not-so-easy part will be clock drivers. If there‘s a difference.