05:20 <valpackett> ok, yeah, https://github.com/quic-kdybcio/linux/commit/36b3dc331a224976d92afa7f6b774e77bfce0e4b fixes nvme on resume from deep. /cc konradybcio

05:21 <valpackett> it's been a few months and the "more driver changes" still haven't been made i guess

09:23 <konradybcio> valpackett: the kernal manages a delicate setup.. for the end user to say "it works", dozens of things need to be perfectly in sync and working, sort of like old Christmas tree lamps - one goes out, all go dark

09:24 <konradybcio> that hack should only be necessary on 8280

10:11 <exeat> steev: my x13s says qcom-battmgr-ac/online=0 and qcom-battmgr-usb/online=1 (when charging), which makes sense

15:29 <valpackett> konradybcio: well, except i do need it currently on x1e

18:04 <derzahl> @JensGlathe[m]: hey my dude, thanks for the work you have done to get the x1p42100 vivobook running!

18:06 <derzahl> im currently running your 6.15.0-rc7-jg-0 kernel from May 20th. Any new worthwhile patches you are aware of?

18:07 <derzahl> any progress on GPU support that you know of?

18:09 <derzahl> wondering if this is relevant: https://lore.kernel.org/all/174860938870.1572047.10505656196850068159.robh@kernel.org/

18:11 <Jasper[m]> The "venus" thing the Mailing List item is talking about is for displaying and/or processing video, as in mp4 files or yt video's. It's also for an older generation of processors than that x1p42100

18:17 <derzahl> oh ok. thanks for saving me the time of bothering with it

18:31 <deathmist> I'd say testing https://patchwork.kernel.org/project/linux-arm-msm/cover/20250530-qcom_battmgr_update-v2-0-9e377193a656@oss.qualcomm.com has been a success on X1E Vivobook: once discharged below set limit and then plugging in it properly retains the set charge percentage even under load and while powered off (including after re-plug while off) :)

18:33 <deathmist> in my case I just made /etc/rc.local write 55 to /sys/class/power_supply/qcom-battmgr-bat/charge_control_{end,start}_threshold in that order. also this test made me realize idle draw on the laptop with nothing at all happening seems to be ~8W without anything plugged in no matter what I seem to try (60 Hz + 1% display brightness + flight mode) lol

18:49 <akhilpo> derzahl, I will try to post the GPU series sometime next week.

18:59 <JensGlathe[m]> Newest development is 4 lanes DP altmode, which works on all my devices - not on all type-c connectors or in all orientations, though. Where it doesn't work it also didn't work with 2 lanes, though, so... maybe some other reason. I have added debug code to get some data on the muxes work, let's see if that helps.

19:06 <JensGlathe[m]> I also added 4 lanes on the x1-general dtsi's for acer, asus which support x1e/x1p42 variants for these laptops. Also the iommu/smmu patch series robclark mentioned. And probably a few other small things. Will be pushed as 6.15.0-jg-4.

19:07 <JensGlathe[m]> https://github.com/jglathe/linux_ms_dev_kit/tree/jg/ubuntu-qcom-x1e-6.15.0-jg-4

19:16 <derzahl> @JensGlathe[m]: awesome. Thanks! so are you still posting the .debs for the built kernels on google drive or somewhere else?

19:17 <derzahl> akhilpo: very nice! how functional is it so far?

19:17 <JensGlathe[m]> yes, there. Not sure if I'm disciplined enough for a ppa

19:22 <JensGlathe[m]> Vivobook? I don't have one, so I'll probably overlook things.My x1p42 testbed is the ThinkBook 16, and this is ... quite... functional. All peripherals except for HDMI out are operational, kb backlight is automatic, secial fn keys don't work (but some , like volume and screen brightness, do). No EC support yet. No GPU support yet. Sound works, fp reader works, camera works. Fan fortunately works and is very potent, so building

19:22 <JensGlathe[m]> on it won't shut the laptop down.

21:30 <akhilpo> @derzahl Works pretty well. Perf obviously be would lower than X1E.

21:37 <JensGlathe[m]> Purwa is pretty efficient with its 8 cores. 55m/8c vs 40m/12c

21:37 <JensGlathe[m]> Package build

22:42 <deathmist> ig partly my 8W X1E Vivobook idle draw is affected by the rgb keyboard backlight constantly cycling which I wasn't able to permanently disable through windows even.. need to get my kernel building somehow with CONFIG_DEBUG_INFO_BTF=y (it fails on subcmd stuff missing linux/compiler.h header currently which seems strange..) so I can try udev-hid-bpf

23:31 <valpackett> deathmist: no way those leds are *that* power hungry 0.o

23:31 <valpackett> any chance you could also have the ath12k spinlock nonsense that so far only i get? check networkmanager's cpu consumption

23:34 <HdkR> A spinlock without using wfe? Traitorous.

23:36 <valpackett> i mean, i see an issue with ath12k where networkmanager's every-6-seconds check up on how the wifi's doing is causing ath12k to spike cpu usage for a second, mostly just in a spinlock, and on average that adds 1W to the power consumption

23:37 <valpackett> have been literally systemctl freezing networkmanager so far to avoid that waste