00:57 <steev> tobhe[m]: fwiw, i bumped to the 6.16 kernel based on johan's stuff, and the t14s has been fairly solid - i was able to build zed editor (8 minutes!) and while it definitely had some temps creep up to 96, the fans were on (doubt they were going full blast) and it didn't shut down or lock up (this is with the badmem option in grub as well as passing mem=32G

01:00 <tobhe> that is good to know! I am planning to upload a 6.16 build based on that soon

01:01 <tobhe> only need to figure out how to not break OLED users during upgrade

01:40 <steev> i'm one so, i can test :D

01:40 <steev> but that does remind that apparently our panel isn't in the kernel

01:51 <steev> and actually i lied, the drm fixes that came in today have made the kernel very angry

01:53 <steev> https://www.irccloud.com/pastebin/jbYyzlAU/

01:53 <steev> just keeps spamming the kernel logs

01:57 <steev> yeah, reverting 5307dce878d4 makes it go away

01:57 <steev> robclark: ^

01:57 <steev> or maybe lumag ?

01:58 <steev> i dunno if it's generic drm issue or if its because msm needs to do something different now?

01:59 <robclark> what is 5307dce878d4? I don't have that in my tree

02:03 <steev> drm/gem: Acquire references on GEM handles for framebuffers

02:04 <steev> it's from linus' tree, earlier today

02:04 <steev> drm-misc-fixes-2025-07-03 - part of this pull request

02:08 <robclark> hmm, not entirely sure that patch is valid but would have to look closer

02:09 <robclark> welcome to the bleeding edge?

02:10 <robclark> I guess report on-list

02:31 <steev> looks like it was reported when it was in -next?

02:31 <steev> https://www.spinics.net/lists/kernel/msg5751889.html - i am trying to figure out how to reply to it when i am not on the mailing lists it went to, normally i find the patchwork and find the git send-email link

02:32 <robclark> I think lore lets you d/l an mbox that you can reply to?

02:36 <steev> https://80x24.org/lore/dri-devel/20250704085541.28165-1-tzimmermann@suse.de/ looks like it might be a potential fix for it, gonna try that first

02:36 <steev> and i dunno why google simply refuses to find the lore link for me

02:37 <robclark> http://lore.kernel.org/all/<msgid>

02:39 <steev> oh that is handy to know

02:43 <steev> okay that fix makes it far worse...

02:44 <robclark> fun

02:45 <steev> or maybe it was just a fluke?

02:50 <steev> now it isnt locking up

10:48 <deathmist> uh is anyone's X1E Vivobook behaving weirdly when it comes to entering UEFI boot menu? mine seems to have entirely given up at some point on showing it when spamming or holding Esc which used to trigger it 100% of the time, now I just get systemd-boot's menu. weirder is that if I disable "Fn Lock Option" the keyboard seems to stop working properly on systemd-boot

10:49 <deathmist> wondering what I could've possibly done to break this now.. at least I could still "bootctl reboot-to-firmware true" after the "Disabled Fn Lock Option" incident but now I feel like I'm playing with fire and the machine can genuinely brick itself if I don't restore the functionality of Escape to trigger the boot menu

10:51 <deathmist> it's running latest 366 UEFI build from Asus and I previously messed with some options in MyAsus, maybe I'll have to go back and see if any of those have an effect

12:07 <binarycraft[m]> <deathmist> "wondering what I could've..." <- At least you could get into bios menu with F2?

13:26 <deathmist> binarycraft[m]: nope, F2 or Fn + F2 do nothing either

13:29 <deathmist> genuinely my easiest way to boot from a USB currently is via windows assuming my current OS/bootloader doesn't get bricked to the point I can no longer even reach userspace to change course. I'm now considering treating windows as a part of the firmware and making it my default boot option just to avoid that..

13:30 <binarycraft[m]> deathmist: I am sure Asus has a magic button to reset uefi/bios settings

15:09 <deathmist> binarycraft[m]: a factory UEFI settings reset later (and secure boot still disabled) and nothing changed if that's what you mean, I can't find any physical button on the device at least for CMOS clear or similar without opening up the chassis. also made windows the default boot option and will now have to make sure it stays that way since it's now officially my only way to

15:09 <deathmist> boot from a USB

17:46 <Hugo[m]1> Jens Glathe: Update on Touchscreen on the Surface Pro 11 (and Pro 9 5G as it shares the same structure):

17:46 <Hugo[m]1> https://github.com/dwhinham/linux-surface-pro-11/issues/10#issuecomment-3039473027

17:46 <Hugo[m]1> It is not a PMICGPIO but a regular TLMMGPIO for power enable.

17:47 <Hugo[m]1> So I now have all the information I need to build a dt overlay

17:51 <JensGlathe[m]> Nice

17:51 <Hugo[m]1> And it was in the SSDT

18:06 <JensGlathe[m]> oh interesting

20:16 <angeloverlain[m]> [Hugo](https://matrix.to/#/@hmelder:matrix.org): is that also maybe applicable to romulus ?

20:34 <JensGlathe[m]> I would say pretty much probable. Microsoft is doing things differently as it seems

20:36 <steev> JensGlathe[m]: do you happen to know which codecs are required for audio on t14s? i'm getting WCD Playback: codec dai not found, but i'm using johan's defconfig so i'd have expected it to be enabled, so wondering what i might be missing

20:44 <JensGlathe[m]> I see q6apmbedai and wcd938x

21:38 <icecream95> deathmist: I've had some problems with entering the boot menu, but plugging in a USB drive with a new boot image seems to help sometimes

21:39 <icecream95> Odd that the "Fn Lock Option" changes things, it doesn't seem to have any effect outside Windows

21:40 <steev> yeah, those modules are loaded, hm

21:41 <icecream95> For keyboard issues, perhaps the keyboard itself is the problem... sometimes keycodes can get stuck on. Try pressing keys such as PrtSc, Fn+K, Fn+B, Fn+P, Fn+F while in UEFI

21:41 <icecream95> There have also been occasions where I've had a USB keyboard working, but not the builtin keyboard

21:43 <icecream95> You could also try to reset/crash the EC, say by sudo i2cget -y 2 0x5b 23

21:51 <icecream95> though it may be on a different i2c device, replace 2 with n from i2c-n in `echo /sys/bus/i2c/devices/*/*/0018:0B05:4543.0002`

22:24 <Hugo[m]1> <angeloverlain[m]> "[Hugo](https://matrix.to/#/@..." <- Probably, but I'd need to look at the DSDT/SSDT to double check.

22:25 <Hugo[m]1> Still need to get around and update the device tree for denali (surface pro 11)

22:26 <Hugo[m]1> We have some pre-production Surface Laptop 7's at work which I can abuse to dump the DSDTs

22:27 <tobhe[m]> there is https://github.com/aarch64-laptops/build/tree/master/misc/microsoft-surface-romulus13_and_15

22:38 <Hugo[m]1> ah even better

22:39 <Hugo[m]1> but the SSDT is missing