00:09 <bumble[m]> do people here have an opinion; is 16gb ram x13s too little ram? does the touch screen draw too much battery? It may be possible to acquire an x13s for a decent price but only with 16gb ram and touch screen

00:09 <bumble[m]> thanks for any opinions that may come :)

00:45 <clover[m]> I've never run out of RAM at 16gb, but also there is no virtualization for the x13s yet AFAIK.

00:46 <clover[m]> Touch screen is great. I use it a lot. Battery life is good it should last a full day of work

01:08 <bumble[m]> okay thanks, sounds good :)

02:27 <steev> Dantheman825[m]: next time you're booted into it, can you do `sudo cat /sys/kernel/debug/devices_deferred` ? it looks like they might be missing something in the kernel config

03:50 <albsen[m]> <bumble[m]> "do people here have an opinion..." <- it really depends on what you do. for my full workload 16gb was not enough (unfortunately) so I had to add 16gb swap into it to make it work which was "fine". now I'm using the x13s with 32gb which works great. mostly due to "teams" meetings, screensharing + jetbrains ide's (clion, pycharm, rider), multiple browsers all open at once ... if u only use a single browser, no teams

03:50 <albsen[m]> meetings and only one ide (or emacs/vim) u should be fine.

04:20 <bumble[m]> yes it seems to me also 32gb is minimum needed for enterprise development routine. 32gb version is almost impossible to find and, where it is available, very expensive.

04:30 <Segfault[m]> i've been perfectly fine with 16gb, i don't even have physical swap set up, just zram, and i've never run into issues

04:32 <Segfault[m]> and afaik the touchscreen draws practically no power, it also doesn't use a super reflective layer like on a lot of other computers so there's no real downside to getting it aside from not being able to get the brighter LPFHD lcd panel

04:32 <Dantheman825[m]> I throw a lot of x86 emulation at this laptop, and thus a bunch of games. Depending on the game, the RAM can totally gobbled up

04:33 <Dantheman825[m]> But this is an unusual usecase for the X13s, it’s not really meant for gaming (which is why I like to run games on it :) )

04:34 <Segfault[m]> in other news my new ssd arrived and so far it seems to be working well, hopefully i don't run into dropouts like with the SN740

04:35 <Segfault[m]> new drive is a 1tb pny cs2142, it uses a phison controller

04:58 <bumble[m]> thanks for the comments

07:43 <\[m]> ok internal screen came up on rc6 with laptop_defconfig for the vpn

07:43 <\[m]> still need to do ifdown / ifup after loginthough

08:39 <Segfault[m]> just gave the in-kernel pd-mapper implementation a go, it seems to work nicely so far

08:40 <\[m]> I created a support ticket for the vpn, seems it's about failing to initialise split tunneling

11:25 <agl> steev: Your Kernel 6.8.7 works fine: Bluetooth mouse, USB-Thethering with mobil phone works. I have not yet testet the sound. I do it when I'am at home.

11:35 <agl> steev: What since 6.8.1 is that I can not switch off the x13s. It makes a reboot not a switch off when I select shut down. This is also in 6.8.7. With 6.7.10 I can do a normal shut down and the x13s is switched off.

12:32 <jhovold> agl: you either need to enable the "Linux mode" option in the UEFI setup or pass in "efi=noruntime" on the command line

12:33 <jhovold> otherwise you'll trigger a reset on shutdown, sounds like you may be hitting that

13:37 <jglathe_x13s> I have efi=noruntime and the boxes don't shut down... this is since 6.8

13:40 <steev> time to learn to love s2idle /s

13:55 <jhovold> jglathe_x13s: then it sounds like there's a broken patch in steev's branch

13:56 <jhovold> I think I saw some reboot related patch from konrad at some point, perhaps something like that

13:56 <jhovold> would be good if you could track it down so that whatever it is doesn't hit mainline

14:01 <jglathe_x13s> will take a look

14:04 <jglathe_x13s> Got 6.8.0-31-generic (Ubuntu) booted up btw, it has the same behaviour. And... there my problematic "blue only screen on resume" 32" 4k display resumes normally. A few things to research.

17:00 <agl> jhovold: I have now tried all 4 options (Linux boot (beta) in UEFI bios and efi=noruntime: off-off, off-on, on-off, on-on). Unfortunately, the shutdown still does not work. A reboot is performed every time. I always rebooted before testing so that the changes were applied. My command line in /etc/default/grub (debian) looks like this: GRUB_CMDLINE_LINUX_DEFAULT=“efi=noruntime pd_ignore_unused clk_ignore_unused arm64.nopauth”.

17:00 <agl> My UEFI bios version is N3HET88W(1.60). Bios Date: 2024-03-14 Machine Type Model: 21BXCTO1WW (German Keyboard Layout).

17:00 <agl> When I start Kernel 6.7.10 the shutdown works.

17:10 <jhovold> agl: sounds like a different problem then, jglathe also hit it with steev's branch

17:11 <steev> jhovold: jglathe is hitting it with the ubuntu kernel, it's not something from my branch

17:11 <jhovold> yeah, he said that too

17:11 <jhovold> but how can it be a mainline issue when I'm not seeing it?

17:11 <jhovold> bad backport to stable/ubuntu?

17:12 <jhovold> related to latest UEFI fw?

17:12 <jhovold> I'm not running the latest, but then 6.7 should also be affected

17:12 <jhovold> got to run, will check in later

17:14 <steev> potentially? i don't have the time as i have something to do by eod, and this t64 stuff is breaking things left and right at the same time

17:14 <steev> i'd probably just grab the linux-6.8.y branch, and defconfig and see if that shows the same issue

17:42 <jglathe_x13s> had the issue starting with bios 1.59

17:45 <jglathe_x13s> this shutdown issue has time I guess, we're supposed to run those boxes

17:55 <Segfault[m]> re the x13s ec, i'm able to read the status register and it seems to respond about how i expected from the acpi dump, i'm still trying to figure out interrupts though

17:57 <jglathe_x13s> nice

17:57 <Segfault[m]> interrupt gpios on these devices are always such a massive pita because the pin numbers in the acpi have very little correlation to actual pin numbers lol

18:08 <jglathe_x13s> I learned it is offset 32 when its GICv3

18:10 <travmurav[m]> even just gpio numbers themselves are randomly offset sadly so it's not "just add x" :S

18:11 <jglathe_x13s> there are several gpio chips, maybe its offset of its starting address ?

18:14 <travmurav[m]> I dont' remember there to be a reasonable rule for it

18:23 <Segfault[m]> with sc8180x there was a rule that'd get you close to the actual pin number

18:24 <Segfault[m]> like the value in acpi - 192 / 32 was the number of wakeup capable gpio or something

18:25 <Segfault[m]> but the values in the x13s acpi make absolutely no sense afaict lol

18:34 <steev> have you compared numbers to what is in the device tree? maybe bamse knows the formula or jhovold

18:35 <Segfault[m]> yes and they seem impossible

18:36 <Segfault[m]> if anyone does know for certain I'd really like whatever pin is 0x0300 in the acpi :P

18:45 <jglathe_x13s> 2E0

18:46 <jglathe_x13s> or 736

18:46 <jglathe_x13s> calculated with offset 32 like for the arm-smmuv3 interrupts

18:50 <jglathe_x13s> probability says its the GICv3 (960 interrupts)

18:52 <jglathe_x13s> and if it's not used somewhere in sc8280xp.dtsi - even better

20:23 <konradybcio> Segfault: https://github.com/SoMainline/linux/commits/topic/ec2

20:23 <konradybcio> pushed the.. not very pretty state of the lab setup i had last time around..

20:29 <Jasper[m]> <Segfault[m]> "but the values in the x13s..." <- I was told they are dynamically assigned by a windows driver

20:29 <Jasper[m]> Using the pin listed in dsdt as the reference

20:30 <Jasper[m]> I also still need to find out the interrupt pin for my hid-over-i2c peripherals in the Book2Go