00:05 <enyalios> robclark: /lib is a symlink to /usr/lib, so thats not it

00:06 <enyalios> thats for digging into that

00:06 <robclark> ok.. then only hint I can think of is what is different about the sqe/gmu fw that the kernel successfully loaded

00:08 <robclark> there are a some diff paths fw load can take (I think mainly depending on CONFIG_FW_LOADER_USER_HELPER .. I have that disabled).. but not entirely sure how that could explain 2 of 3 fw files loading ok and the 3rd not..

00:09 <enyalios> yeah, and the thing that is confusing me is that it works on one kernel version but not the other

00:17 <robclark> on the "working" dmesg you pasted, it was also having trouble loading zap.. so gpu not working may be unrelated to video not working (but would at least make video rendering a lot less efficient)

00:18 <robclark> (and from the looks of it there is some badness in the "zap fail" error path.. admittedly that is probably not a well tested error path)

00:57 <enyalios> robclark: yeah there still seemed to be a lot of errors in the working one too which was surprising

00:59 <robclark> in the ideal case (but idk if mkv/etc supports this) the decoder would output NV12+UBWC frames which would require the GPU to render.. this will be more efficient from a memory bw standpoint (but I guess if sw rendering worked, then either mkv doesn't support UBWC or it disables it)

12:29 <bibikski> T14s Friends: What process did you perform to get the T14s to boot your OS?

12:31 <JensGlathe[m]> There's a patch from jhovold that needs to be in the kernel to increase the chance, there seems to be a bug in the UEFI

12:32 <bibikski> Thanks, I'll try it out

12:33 <tobhe_> also have a look at https://aarch64-laptops.github.io/distro_integration.html if you plan to port sth new!

12:34 <JensGlathe[m]> This one https://lore.kernel.org/lkml/Z0gn1N3IsP8r3gTA@hovoldconsulting.com/

12:35 <bibikski> I'll check it out! I went the mkosi route and I am super close to booting, but regardless of the modules and everything the screen still blanks out. Speculating the modules aren't being loaded, but I'm unsure at this time

12:37 <tobhe> also: is this the 64GB T14s? there is more bugs with that one

12:37 <bibikski> Unfort yes

12:37 <bibikski> I thought it would be a good idea given the soldering of the ram o_O

12:38 <tobhe> it is in theory but unfortunately there is a bug when you use the upper 32GB

12:39 <tobhe> bibikski: in grub we have to use "cutmem 0x8800000000 0x8fffffffff" to make it boot

12:40 <JensGlathe[m]> *tobhe has one and could try that

12:41 <tobhe> I know but I don't have el2 set up and haven't had time yet unfortunately with release coming up...

12:42 <bibikski> Yeah I haven't touched grub for the install yet, still trying to boot of the usb. I'm currently dealing with a weird scenario where I have multiple initrds being loaded, possibly due to the nature of mkosi-qcom. I was experimenting by adding more initrds and stacking them, at that point I then got a bright blue screen.

12:42 <bibikski> What is e12?

12:43 <travmurav[m]> tl;dr virtualization/kvm is locked down by very weird design choice but we can boot linux in EL2 (hypervisor level) to get KVM work; I strongly suspect that 32GiB issue is in gunyah which would be dead if linux takes its place

12:43 <travmurav[m]> (gunyah == qcom's proprietary hypervisor that runs by default, windows replaces it with hyper-v so it's not affected is the theory)

12:44 <bibikski> Ah. Thnak you

12:45 <travmurav[m]> https://github.com/TravMurav/slbounce fyi

12:47 <bibikski> Is the dtbhack.efi worth trying? My os is loading the device tree

12:48 <travmurav[m]> for x1e just need to apply the changes to the dts according to the overlay file

12:48 <JensGlathe[m]> you need it for the modifications. need accessible arm-smmuv3, and no zap -shader node

12:49 <bibikski> Okay, then I'll read up on this more

12:49 <travmurav[m]> i.e. alternatively can fdtoverlay -i my-laptop-dtb -o my-laptop-el2.dtb x1e-el2.dtbo

14:27 <anthony25> On my yoga slim 7x, the animations on hyprland can be laggy when I'm on battery, but when on AC I don't have the problem. What can I look to make the CPU and GPU scheduler a bit snappier on battery?

14:28 <anthony25> scheduler/governor

14:29 <anthony25> the stutters in the animations happen mostly if the laptop was idling, like switch from a workspace from a terminal to firefox

14:31 <travmurav[m]> is it same if you force cpu to work with performance governor?

14:32 <anthony25> it's better with performance governor

14:32 <travmurav[m]> for schedutil I think there is uclamp to let it know some task needs more performance but not sure if x1e is asymmetric enough for it to change as much

14:32 <anthony25> I looked at the uclamp, it's already really low

14:33 <anthony25> it's set at 45

14:33 <travmurav[m]> well what if you set min uclamp to like 768 for the de?

14:35 <anthony25> ha I can set a min uclamp per process?

14:35 <travmurav[m]> uclampset --pid $(pidof gnome-shell) -m 900

14:35 <travmurav[m]> obviously don't want to set system-wide knobs xD

14:35 <anthony25> oh nice

14:36 <anthony25> ok I'll try, thanks a lot!

14:36 <travmurav[m]> ^^ is very noticeable on lower end systems (i.e. big.little 7c1) where shceduler would much more eagerly put de on fast cores with high minimal uclamp (and I think scale the freq up more rapidly for them)

14:37 <anthony25> ha nice, so it forces the scheduler to keep my WM on big cores?

14:37 <travmurav[m]> but I think x1e has all same cores (tho I guess there are few that are allowed to boost more)

14:37 <travmurav[m]> as far as I understand uclamp, yes

14:37 <travmurav[m]> s/forces/suggests though

14:37 <anthony25> true

14:39 <anthony25> actually that's a really good point, I'll see also if the uclamp values change if I'm on battery or AC

14:39 <travmurav[m]> I'd also wonder if firmware somehow affects boosting on AC

14:40 <travmurav[m]> afaiu x1e does quite more stuff in firmware compared to older things

14:41 <anthony25> I also thought about it

14:41 <anthony25> the firmware binaries on the slim 7x are quite old, if I understood correctly

14:41 <travmurav[m]> since afaiu the charger is part of qcom chipset I'd not be surprised it's all heavily integrated

14:42 <travmurav[m]> that is, I had a strong impression that x1e devices just have a bunch of qcom chips like pm/smb pmics for everything under the sun and qcom likes to tightly integrate everything

14:42 <travmurav[m]> which is why we get charger working depending on adsp

14:43 <anthony25> https://www.reddit.com/r/snapdragon/comments/1imx4qb/lenovo_yoga_slim_7x_qualcomm_signed_drivers_coming/

14:43 <travmurav[m]> but I guess not like this bridge has long to live anyway...

14:44 <anthony25> hopefully this bios will be shipped soon

14:45 <craftyguy> Has anyone been able to flash a recent x13s bios without using windows?

14:49 <robclark> anthony25: is something in userspace changing scheduler or something like that when you switch btwn AC and battery? Maybe your distro has some misguided x86 oriented battery optimization?

14:51 <anthony25> robclark: I'll check, but I don't think so (it's running Tumbleweed)

18:48 <anthony25> hmm, so after testing again, the slowdowns are in fact still happening even on AC, and even with the performance governor on the CPU and GPU

18:48 <anthony25> uclampset seems to help, however

18:49 <anthony25> so it might be hyprland being slow to render something

18:59 <roy> Hi! Trying to boot my t14s (non-oled) with jhovold's 6.14 branch. It is almost working, but stuck on getting the GPU to initialize enough to run swaywm. The msm driver is loaded, but it is failing to detect/initialize the hardware. sway starts fine on Ubuntu

19:01 <roy> full dmesg https://bpa.st/DMHQ this line looks different to ubuntu, `msm_dpu ae01000.display-controller: bound 3d00000.gpu (ops msm_hdmi_hdcp_transfer_v_h [msm])`, on ubuntu it reads `... (ops a3xx_ops [msm])`

19:01 <roy> any help appreciated :)

19:23 <steev> you seem to be missing firmware

19:29 <roy> I saw that fw was loaded after initrd - `[ 17.017631] msm_dpu ae01000.display-controller: [drm:adreno_request_fw [msm]] loaded qcom/gen70500_sqe.fw from new location` so thought its ok

19:31 <roy> or... is there more? I could not see anything different in the ubuntu dmesg though

19:33 <tobhe> adsp and cdsp seem to be missing. you can get them from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/x1e80100/LENOVO/21N1

19:34 <tobhe> maybe also from a nix linux-firmware package

19:36 <roy> thanks. I'm pretty sure it should be using linux-firmware already, so i will look into this

19:40 <robclark> anthony25: hmm, odd.. I don't _think_ the fw should be controlling cpu freq too much, compared to x86 (ie. lots of that stuff is in acpi on x86, but in drivers in kernel on dtb systems)... maybe `perf record -a sleep 5` while triggering animations and then `perf report` in both cases.. or even just compare htop, and see if something is using more cpu on AC vs battery?

19:41 <robclark> I guess I could do more testing on battery... but my external display also provides power so I can't help but be on AC a lot of the time

20:13 <roy> IDENTIFY

20:14 <roy> with the firwmare blobs, but still no GPU. dmesg is now https://bpa.st/XOKA

20:22 <robclark> roy: dmesg looks ok.. what mesa version?

21:41 <roy> robclark: that was a very good question.

21:41 <roy> Turns out that the system was not linking the mesa driver in the right place. Must have been something leftover from one of the previous failed installs

21:42 <roy> with that fixed graphics comes up just fine

21:43 <roy> i really wish that error message was a little bit more descriptive

21:43 <roy> thanks for the help

21:45 <robclark> np, glad you got it working