09:53 <erebion3421EPVPN[m]> steev: Yes, thank you. So that remoteproc stuff is related to battery readings, TIL. Now I know where to look. :D

10:01 <erebion3421EPVPN[m]> Also, when the X13s runs out of battery, it gets into a state where the power button LED is on, but I cannot turn it back on without pressing the reset button multiple times. This only happens when it runs out of battery overnight.

10:02 <erebion3421EPVPN[m]> Do we know anything about that? Can I change that behaviour somehow? I don't always have a paperclip with me... :/

10:23 <alexVinarskis[m]> <erebion3421EPVPN[m]> "Also, when the X13s runs out..." <- I had something similar on Dell XPS 9345. When fully discharged, it just won't boot, Dell logo appears, but not going further, restarts don't help, typically just lead to BIOS ROM error. Nor will it charge (just 3-5w consumption). Doing pretty random things to recover from that state - recent BIOS update (iirc 2.2) seems to have fixed it, maybe there is one for your

10:23 <alexVinarskis[m]> machine too?

10:52 <erebion3421EPVPN[m]> No BIOS ROM error, but the LED makes it look like it is in suspend and cannot wake up, but must be something else, as suspend works when I trigger it. weird.

10:58 <erebion3421EPVPN[m]> So... There's a firmware update, do I just download the exe and use geteltorito to turn it into an iso that I then boot, like for other Thinkpad models?

11:01 <erebion3421EPVPN[m]> "This data image does not seem to be a bootable CD-image"

11:01 <erebion3421EPVPN[m]> Huh, nope

12:11 <erebion3421EPVPN[m]> If anyone could enlighten me, please let me know how I can update the firmware of an X13s 🤔

12:57 <dgilmore> erebion3421EPVPN[m]: you will need to do it from windows. the efi updater has not worked for the last couple of releases

13:57 <freekurt[m]> After unlocking my LUKS encrypted SSD I often get dropped into an ash BusyBox shell instead of the screen to log in as my Ubuntu user when my battery is low on my x13s. Doesn't seem to happen when my battery isn't low though.

14:18 <jhovold> Here's an updated wip branch for the X13s:

14:18 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.15-rc1

14:18 <jhovold> Changes include:

14:18 <jhovold> - fix camera registration race that breaks boot

14:18 <jhovold> - fix camera hw version log spam (6.15-rc1 regression)

14:19 <jhovold> - enable ucsi and usb-pd

14:19 <jhovold> - rename pci pwrctrl kconfig symbols

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

14:19 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.15-rc1

14:19 <jhovold> Changes include:

14:19 <jhovold> - fix camera registration race that breaks boot

14:19 <jhovold> - fix camera hw version log spam (6.15-rc1 regression)

14:19 <jhovold> - fix hp x14 usb and display

14:19 <jhovold> - enable t14s headset jack

14:19 <jhovold> - enable t14s modem

14:19 <jhovold> - enable t14s-oled display

14:19 <jhovold> - rename pci pwrctrl kconfig symbols

14:19 <jhovold> - johan_defconfig: enable CONFIG_MUX_GPIO

14:19 <jhovold> Known issues:

14:19 <jhovold> - audio codec mux lookup error on non-t14s

16:39 <bionade24_> Hi, the ACPI table files in the build repo files are for documentation only and one needs to write device tree files for everything, aren't they?

16:39 <bionade24_> I've seen more Laptop model dirs contain a .dts file, but many don't

16:44 <Jasper[m]> bionade24_: Correct!

16:44 <Jasper[m]> Do you have a laptop in mind?

16:44 <bionade24_> Jasper[m]: I already have a Hyrican (Study|Enwo)-Pad-One

16:45 <bionade24_> Is there some tool that can at least partially convert the .dsl files to .dts or does it all have to be done manually?

16:46 <Jasper[m]> Ohhh interesting stuff. I don't think that's in the aarch64-laptops repo yet.

16:46 <Jasper[m]> No you will have to do it manually

16:46 <bionade24_> Does it make sense to start by copying an existing .dts file from the repo?

16:46 <Jasper[m]> But the Snapdragon 845 and 850 are fairly well supported. You could try to compare the tables you have with the dts for another yes

16:47 <Jasper[m]> This is ESPECIALLY important for regulators and such

16:48 <bionade24_> Jasper[m]: Ok thanks. I guess it's best if let someone from here look over my .dts files before trying to boot with them for the 1st time then?

17:31 <Jasper[m]> Of course, I'm sure there are people happy to help. I would first start by dumping acpi

17:33 <steev> tobhe: was the 4GB patch that ubuntu uses accepted upstream?

17:35 <bionade24_> Jasper[m]: Already did that before asking here. I've also seen that someone already got the thing to boot with the matebook kernel.

17:37 <Jasper[m]> Interesting! Do you have a link?

17:37 <Jasper[m]> I think I had seen the Pipo W12 naming around, but couldn't find it

18:04 <tobhe> steev: which one exactly? the grub hack?

18:04 <steev> tobhe: i was thinking the 4GB limit one?

18:05 <steev> i'm not sure if that is considered a hack or not

18:10 <tobhe> I don't think it was upstreamed yet, but I guess it would make sense to so

18:12 <tobhe> I think previously there were concerncs that it is a bit intrusive to work around a device specific bug. otoh a lot of other platforms enforce the same limit

18:13 <tobhe> iirc someone tried doing the same on risc-v and it broke some machines

18:30 <kuruczgy[m]> d0pefish: Did you submit some of your Surface Pro 11 patches upstream (I could not find anything on lore.kernel.org), or do you plan to?

18:30 <kuruczgy[m]> Also, where did you cherry-pick that updated spi-hid driver from?

18:44 <tobhe> steev: https://lists.gnu.org/archive/html/grub-devel/2025-04/msg00072.html

18:44 <Jasper[m]> @kuruczgy maybe at linux-surface?

18:44 <kuruczgy[m]> Jasper: Is that an IRC channel or a mailing list?

19:59 <kettenis> tobhe: doesn't that diff break machines without memory <4G?

20:00 <kettenis> like all the apple machines and the amd seattle machines?

20:11 <tobhe> it possibly does

20:17 <jannau> yes, it looks like the sd-boot issue from last year

20:19 <jannau> https://github.com/systemd/systemd/issues/35026

20:21 <tobhe> thx jannau

20:37 <Jasper[m]> @kuruczgy github repo https://github.com/linux-surface/spi-hid (this is a downstream version though, their kernel trees may contain a driver with better compay)

20:37 <Jasper[m]> *compat

20:41 <kuruczgy[m]> Ah, thanks. Though the last update being 3 years ago does worry me a bit about compatibility with new kernels

20:44 <Jasper[m]> @qzed should be in this channel I think? Pretty sure spi-hid is rebased often right?

20:44 <Jasper[m]> (the matrix user is not showing up so maybe not)

20:45 <qzed> I'm here... and that is quite outdated

20:46 <tobhe> indeed it doesn't work on my m2. Guess we might need to make this an X Elite only quirk then

20:46 <Guest13105> This should be relatively up-to-date: https://github.com/linux-surface/kernel/tree/spx/v6.13/drivers/hid/spi-hid

20:48 <Jasper[m]> qzed, thanks couldn't find it while scrolling through commit history. I knew the other one was a downstream driver from the duo2, but wasn't sure where the other was

20:49 <qzed> Yeah... that basically is only on the spx/... branches because the main kernels over there are still x86 oriented

20:49 <Jasper[m]> s/the other was/the newer one was/

20:50 <qzed> I mean this is till downstream from the duo2, there was some newer on a mailing list some time ago, but I never got that to work

20:50 <qzed> *still

20:50 <Jasper[m]> Then the princess may still be in another castle hahahaha

20:51 <qzed> I think this was it: https://lore.kernel.org/linux-arm-kernel/86b63b7b-afda-d7f4-7bfa-175085d5a8ef@gmail.com/T/#mbbdd71ea21bc9f1f0ecff97cf3e0b198e7265885

20:53 <Jasper[m]> I hate that they do the mandatory cryptomining captcha now