03:54 <dgilmore> does anyone know much about the 2.20 bios update for the t14s that was released last week. looks like some minor changes in the changelog, but not sure they are relevant for things in Linux

04:18 <steev> just a quick read of the readme, it seems related to windows "modern standby" feature

04:22 <dgilmore> I installed it. there are a few CVE fixes also

04:44 <genius1237[m]> gonna sound like a odd request, but could someone try unplugging their battery, try booting and see if they get usb c video out (or hdmi too) during this bios/grub stage? for some context, I'm trying to see if I can get my laptop mobo to boot without the internal screen (it's broken) and battery plugged in.

04:45 <genius1237[m]> I get video out only when I reach the os, so it seems like whatever is supposed to load the adsp fws in the uefi stage isn't doing it if the battery isn't there (or is this hypothesis wrong?)

04:46 <genius1237[m]> (x1p42100 ideapad 5 2 in 1 here)

11:39 <kuruczgy[m]> I am now getting the "[drm:dpu_crtc_frame_event_cb [msm]] *ERROR* crtc108 event 1 overflow" error on a fresh boot, without suspend or any DP altmode devices plugged in (and the accompanying random freezes)

11:39 <kuruczgy[m]> I really don't wanna bisect this, bisecting intermittent issues is a nightmare... (so far it seems that this regression got introduced between 6.15 and 6.16-rc1, still present in rc2)

11:44 <alexVinarskis[m]> same, i didn't want to start another mega bisect... if you will though, keep in mind that in linux-next-20250516 IRQ bug [1] was introduced which at least in some cases breaks wake up on x1e. it was fixed since, but if you go back may need to revert commit or apply fixup. [1] https://lore.kernel.org/all/24ec4adc-7c80-49e9-93ee-19908a97ab84@gmail.com/

11:45 <alexVinarskis[m]> i dont recall exaclty now, but i dont think i had this freezing issue and dpu errors on linux-next prior to that bug/on linux-next-20250513 iirc. Might be a good starting point.

11:51 <erebion> steev: Want more knowledge? The EFI is buggy. It can happen that it becomes impossible to boot when enrolling any keys (but does not have to always), then you turn off Secure Boot and it is still on. Rather than flashing I found a simpler trick: Just get it back to a consistent state by deleting all keys, restoring factory keys, setup mode, restoring factory keys, exit and save changes. Suddenly b

11:51 <erebion> ooting works again.

11:51 <erebion> I'm thankful JensGlathe[m] provided the image, but in the end the solution could have been much simpler, as I discovered.

11:52 <erebion> It's just broken software.

11:56 <erebion> sbctl --enroll-keys and then bootctl... it still says Secure Boot: disabled

11:56 <erebion> BIOS as well

11:56 <erebion> but does not want to boot after that

11:56 <erebion> Luckily I know have a workaround for getting the system booting again in 25 seconds

11:56 <erebion> just annoying

12:07 <erebion> Okay, setup mode, clear all keys, setup mode, exit and save changes

12:07 <erebion> That's literally all that is required to recover from a non-booting system with broken Secure Boot state

12:07 <erebion> X13s BIOS really needs to get fixed...

13:14 <erebion> Still having issues updating the BIOS

13:14 <erebion> The updater just reboots the laptop

13:15 <erebion> Was hoping the newer BIOS might not have the bug enrolling Secure Boot keys, but cannot find out if I cannot update... :/

13:58 <jhovold> Here's an updated wip branch for the X13s:

13:58 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.16-rc3

13:58 <jhovold> Changes include:

13:58 <jhovold> - fix interconnect icc_bw_lock lockdep splat (6.16-rc1 regression)

13:58 <steev> erebion: make sure you have > 50% battery; also it should be possible to do it from inside linux with fwupd

13:58 <jhovold> - fix broken (pcie) irqs after suspend differently (6.16-rc1 regression)

13:58 <jhovold> Known issues:

13:58 <jhovold> - microphones broken with alsa-ucm-conf 1.2.14 (revert to 1.2.13)

13:58 <jhovold> Here's an updated wip branch for the T14s and X Elite:

13:58 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.16-rc3

13:58 <jhovold> Changes include:

13:58 <jhovold> - fix broken (pcie) irqs after suspend differently (6.16-rc1 regression)

13:58 <jhovold> - enable bluetooth on dell xps

13:58 <jhovold> Known issues:

13:58 <jhovold> - eusb2 phy module has been renamed (e.g. Kconfig and initramfs)

14:07 <erebion> steev: Flash Utility says 25 %

14:07 <erebion> Should have more than 25 %

15:02 <krzk> Funny thing, I poked and got more people responding and confirming my T14s issues (bamse jhovold) - to recap - my T14s experiences sudden freezes in GUI followed by hard reboot. Mostly during/after intesive work or some Firefox activities, but not always. I thought I was the only one and no one was reporting it neither here (At least not in specific) nor on our slack... but turns out multiple

15:02 <krzk> people have something like that on t14s and a bit similar on Inspiron 14p

15:03 <krzk> My issues started ~month ago, after 4 days after I plugged diffrent stronger power supply, which I then reverted/returned to standard one, and I failed to identify the actual difference month ago.

15:05 <krzk> I still cannot identify the cause of freezes. Sometimes it is often - every boot, every 2 minutes, sometimes works no poroblem for 2 days. Nothing in dmesg, nothing in logs. Froze/reboot also without power supply at least once. Only common case - having display/Gnome working, sometimes even moving mouse.

15:07 <krzk> That's on every kernel and on newest firmware (from may). I am trying now getting anything with diag/qxdm. Anyway, bamse, if you collect issues for firmware folks, please share this one because it seems it affects multiple folks, not only me.

15:18 <jhovold> krzk: iirc you said it started happening also with previously working kernels, which should rule out a kernel regression

15:19 <jhovold> it's possible that some user space update (mesa, gnome, ...) could trigger an existing issue, though

15:28 <krzk> jhovold: yes, although I checked dpkg.log around week earlier and only thing was: installing qemu packages, which later I dropped

15:28 <krzk> after briefly noticing awesome performance when hw emulating arm on arm... :)

15:32 <bamse> krzk: i've experienced the very same hang and reboots on the dell xps

15:35 <krzk> This makes me very happy, because I really did not want to be the unique in that aspect :)

16:14 <bamse> krzk: unfortunately i didn't start to really use the xps until recently, so while it feels like i've only seen this problem since v6.16-rc, i can't say for sure...

16:19 <krzk> When it started happening in my case, I booted back v6.14 and it was there as well. So v6.14, v6.15 and now v6.16.

16:36 <steev> krzk: about the qemu arm on arm.... yeah... you can try setting/passing QEMU_CPU=max,pauth-impdef=on - but also, it seems somewhat related to the gcc patchset for CVE-2023-4039 (which, in my notes... apparently i forgot to link the patchset...) but i honestly gave up tracking it down after getting the above workaround, which is still far slower than it had been. but getting anyone to care.... as soon as you mention qemu, they dismiss

16:36 <steev> and say "find a reproducer without qemu otherwise talk to the qemu peeps"

16:36 <steev> and the qemu peeps say it's not their issue

16:56 <erebion> seetv: How do I update it with fwupd? It says there's no update. I know there is.

17:03 <bamse> krzk: upstream v6.14... or some derrivative of johan's kernel?

17:08 <steev> erebion: https://gitlab.com/TheOneWithTheBraid/x13s-firmware-update/-/merge_requests/1

17:10 <hogliux> krzk: valpackett, TheBITLINK and I have all experienced this issue only after swapping out our SSDs on our slim 7x. Did you do that as well?

17:11 <hogliux> krzk: Also not everyone seems to be hitting this issue. I run the exact same kernel on the same model of slim 7x as kuruczgy. But last time I asked kuruczgy, he hasn't had the issue happen to him ever.

17:12 <hogliux> Also for some people (like for me and TheBITLINK) it also occasionally happens in Windows which leads me to believe that it might be a hardware issue that's unfixable.

17:13 <hogliux> I've been trying to fix this issue for a year now but have made no progress.

17:23 <erebion> steev: Neat. fwupd refuses to update because the battery level does not work, what's required for that? Can't find the right thing. Some sort of firmware?

17:29 <erebion> Cable is not connected, but it refuses to update because it cannot see that -.-

17:30 <steev> erebion: i've never tried to update the firmware when the battery is < 50% i was pretty sure it says to keep it powered on and connected to a power source

17:32 <erebion> It is charged

17:32 <erebion> I believe I might just be missing a kernel module

17:33 <erebion> Random Reddit advice that helped: "Set IgnorePower=true in /etc/fwupd/fwupd.conf then reboot or restart services."

17:34 <erebion> Still, something is missing for the battery

17:41 <erebion> After enrolling Secure Boot keys, the state goes from Setup Mode to Disabled. wtf?

18:15 <anthony25> Yeah that's why I told you before to switch to setup mode, I had a gigabyte card that had a broken bios after update, and the secure boot mode didn't flip correctly

18:16 <anthony25> Switching it to setup and then resetting the keys worked in that case

18:16 <anthony25> Happy you could fix it!

18:23 <kuruczgy[m]> hogliux: yep, can confirm, still never had the "freeze+nothing in logs+reboot" issue occur. I have never swapped the SSD or opened up the machine, so this matches up with your theory.

18:25 <kuruczgy[m]> hogliux: btw I wanted to ask, how are you consuming my kernel, given that AFAIK you are not using NixOS? Do you build using Nix and extract just the kernel, or do you manually build it? (Unfortunately I recently made the process quite a bit more complicated with all the cherry-picks and b4 commands I added.)

18:57 <erebion> anthony25: State yesterday was so b0rked, just flipping it once did not help

19:06 <erebion> Anyone else managed to get Secure Boot working on the X13s?

19:06 <erebion> Trying to figure out why it works fine on one device, but not the other.

19:10 <hogliux> kuruczgy: I'm basically at this commit https://github.com/kuruczgy/x1e-nixos-config/commit/997a40af51e7f4fe43d1c6359d682e897c6ad55e

19:11 <hogliux> kuruczgy: I just manually apply the patches from your .nix files

19:34 <kuruczgy[m]> hogliux: Ok, on main I moved e.g. the bluetooth patch to a b4 shazam command instead of the kernelPatches list, make sure to pay attention to that.

20:08 <kuruczgy[m]> What's the status of gamma adjustment (night light, gammastep, etc.) on X1E?

20:08 <kuruczgy[m]> For me gammastep right now gives "Warning: Zero outputs support gamma adjustment.". Which part of the stack is currently missing/buggy?

20:20 <anthony25> Freedreno doesn't support gamma change, from what I understand

20:21 <anthony25> Hyperland provides hypersunset that uses a shader instead of a gamma change

20:25 <anthony25> robclark: ^

20:26 <kuruczgy[m]> From what I understood CTM needs to be used which is already implemented for freedreno, but I guess compositors don't support it yet? Is this something to bring up with wlroots?

20:27 <kuruczgy[m]> Another thing: I just upgraded to 6.16-rc3, and remoteproc0 does not boot, so no battery status, weird...

20:28 <kuruczgy[m]> Hm wait so remoteproc0 is "attached" and remoteproc1 is "running" on both rc2 and rc3, so it's something else

20:29 <valpackett> kuruczgy[m]: CTM?

20:29 <robclark> so technically ctm/gamma is part of the display (dpu part of the drm/msm driver).. CTM can implement night light, that is how we did it on CrOS. But some devices could in theory support more advanced color processing not supported upstream yet

20:29 <robclark> color transform matrix

20:30 <valpackett> does cros have a non upstreamed patch?

20:31 <valpackett> oh hm so dpu_crtc does have _dpu_crtc_get_pcc_coeff and stuff

20:31 <valpackett> but it's not hooked up to the api??

20:31 <kuruczgy[m]> robclark: What I need it to implement is wlr-gamma-control-unstable-v1 ( https://wayland.app/protocols/wlr-gamma-control-unstable-v1 )

20:31 <kuruczgy[m]> So do I understand correctly that the kernel interface is there to implement this, it just needs work on the compositor side? If I bring this up with the wlroots devs, is there some more detailed docs on CTM that I could reference?

20:33 <jannau> kuruczgy[m]: kwin (wayland) supports nightlight via CTM

20:33 <robclark> ctm is basically a matrix multiply.. idk if you can achieve gamma ramp with that, but I'm not an expert on color

20:34 <valpackett> pretty much everyone uses the gamma lut uapi for this

20:34 <valpackett> so drivers call drm_mode_crtc_set_gamma_size() and drm_crtc_enable_color_mgmt with non-zero size

20:35 <jannau> kwin uses gamma lut as well but if it's not available it falls back to CTM

20:35 <robclark> valpackett: ctm is upstream.. and should be supported on more or less everything.. some higher tier dpu's (like laptops, but not sc7180) do support something more advanced but for $reasons this isn't upstream

20:35 <kuruczgy[m]> So CTM is just a 4x4 matrix, right? The wayland protocol I linked above seems to accept an fd with a whole gamma ramp, so indeed it seems that this cannot be mapped losslessly to a single fixed size matrix.

20:37 <valpackett> any links to the non upstreamed patches? 0w0

20:38 <valpackett> so strange that gamma is such a new feature on qcom.. mtk has a dedicated gamma hw block even on ancient low-end garbage like mt8167

20:40 <kuruczgy[m]> Ah there is a 7 year old wlroots issue... https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1078

20:40 <kuruczgy[m]> "The CTM cannot be used to implement the gamma-control-v1 protocol: it's a 3×3 matrix, and the protocol uses 3×1D LUTs."

20:40 <robclark> hmm, might be 3x3?

20:42 <robclark> not sure how to link to it directly, but https://www.kernel.org/doc/html/v4.11/gpu/drm-kms.html#plane-composition-properties search for "CTM":

20:42 <robclark> yeah:'

20:42 <robclark> https://www.irccloud.com/pastebin/Jh0iYCLR/

20:44 <valpackett> robclark: speaking of dpu i was looking at the PSR code recently comparing to intel.. i've been told here that PSR code has "bitrotted" but it mostly seems to be lacking features.. could it be that my panel doesn't keep the actual image without DP_PSR_FRAME_CAPTURE?

20:44 <anthony25> But gammastep does not support CTM

20:48 <kuruczgy[m]> anthony25: Yep, becuase it's not gammastep's job to support CTM, gammastep supports the relevant wayland protocol, which is currently wlr-gamma-control-unstable-v1. This protocol by design cannot support CTM.

20:48 <kuruczgy[m]> It seems that this issue is being recognized and the idea for a new/updated protocol has been brought up: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4815#note_2959976

20:49 <valpackett> hogliux: krzk: TheBITLINK: mine is a latitude-7455; only ran windows for under a day and never tried linux on the stock ssd; recently updated the bios to 2.10.1 (from 2.8.0) and currently running with a record 5 days of uptime (previous record was 4 days and a few hours)

20:51 <anthony25> kuruczgy[m]: oh interesting, I didn't know

20:52 <kuruczgy[m]> Hm now booting 6.16-rc3 again it seems the battery readout is working. Was this just a one-off? I can't see anything fishy in the boot log of that boot.

21:06 <valpackett> hogliux: krzk: TheBITLINK: oh also at one point the hangs seemed somewhat correlated to any kind of audio playback but i'm pretty sure that was a coincidence. high load definitely seems to be anti-correlated for me, the hangs always happened when not really doing anything, either just moving the mouse or once even during the night afk.

21:37 <kuruczgy[m]> alexVinarskis: don't wanna jinx it but it seems the issue is fixed in rc3? I suspend/resumed a few times with and without DP plugged in, seems fine. Will pay close attention in the next few days.

21:49 <valpackett> huh, the sm8750 which also uses oryon cores does have a system_pd with the domain_ss3 sleep state..