#aarch64-laptops on 2025-05-29 — irc logs at oftc.catirclogs.org

2024-07-16 04:52 ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops

00:08 chrisl has joined #aarch64-laptops

00:16 chrisl has quit [Ping timeout: 480 seconds]

01:12 chrisl has joined #aarch64-laptops

01:14 rmsilva- has joined #aarch64-laptops

01:17 rmsilva has quit [Ping timeout: 480 seconds]

01:20 chrisl has quit [Ping timeout: 480 seconds]

01:37 pabs has quit [Read error: No route to host]

01:39 pabs has joined #aarch64-laptops

02:04 chrisl has joined #aarch64-laptops

02:14 chrisl has quit [Ping timeout: 480 seconds]

02:22 chrisl has joined #aarch64-laptops

02:30 chrisl has quit [Ping timeout: 480 seconds]

02:45 tobhe has joined #aarch64-laptops

02:46 hexdump01 has joined #aarch64-laptops

02:48 hexdump0815 has quit [Ping timeout: 480 seconds]

02:51 tobhe_ has quit [Ping timeout: 480 seconds]

03:30 chrisl has joined #aarch64-laptops

03:32 todi has joined #aarch64-laptops

03:38 chrisl has quit [Ping timeout: 480 seconds]

03:41 <valpackett> huh. one random missing thing: night light etc. - msm/dpu has no gamma lut support

03:56 tstachecki has joined #aarch64-laptops

03:58 tstachecki-laptop has joined #aarch64-laptops

03:58 <tstachecki-laptop> playing with the rtc on the pm8xxx tonight - two fun observations...

04:00 <tstachecki-laptop> 1) https://github.com/tj90241/linux/commit/cb7a135e18ace66ab5833232ace45dcb12a3ded4 - to get jhavold's uefi offset storing/loading to work for the rtc offset (reliably), i had to move the pm8xxx rtc mod after uefisecapp registered efivars or it would sometimes just load time epoch as 0

04:01 <tstachecki-laptop> 2) seems like windows stores some kind of persistent tz offset somehow to pm8xxx rtc offset? when i change TZ in windows, it affects what the time the surface7 sees in linux when it reads the rtc

04:04 Core5792 has joined #aarch64-laptops

04:04 tstachecki has quit [Read error: Connection reset by peer]

04:13 luca020400 has quit [Quit: WeeChat 4.6.1]

04:13 luca020400 has joined #aarch64-laptops

04:37 chrisl has joined #aarch64-laptops

04:45 chrisl has quit [Ping timeout: 480 seconds]

05:09 tstachecki has joined #aarch64-laptops

05:09 Core5792 has quit [Read error: Connection reset by peer]

05:13 <steev> makes sense (somewhat) since windows by default (did?) store(s) the time in local, not utc

05:19 <tstachecki-laptop> yeah, just really annoying as the surface bios does let you set TZ and the EFI variable that holds the TZ doesn't seem to do anything when I poke it in linux

05:19 <tstachecki-laptop> surface bios doesn't let you set TZ*

05:20 <tstachecki-laptop> if you can't set it and its not UTC, everytime you startup the laptop the time is wrong by some hours because writes to the RTC directly are blocked and the offset is only stored in UEFI right now

05:28 <steev> you should be able to tell windows itself to use utc

05:30 ungeskriptet_ has quit [Remote host closed the connection]

05:30 <tstachecki-laptop> i can, but intend to blow out linux and i don't know how persistent the setting is. imagine its in some kind of volatile ram.

05:30 ungeskriptet has joined #aarch64-laptops

05:30 <tstachecki-laptop> blow out windows* for linux

05:39 tstachecki-laptop has quit [Ping timeout: 480 seconds]

05:44 chrisl has joined #aarch64-laptops

05:52 chrisl has quit [Ping timeout: 480 seconds]

06:14 Core5712 has joined #aarch64-laptops

06:14 tstachecki has quit [Read error: Connection reset by peer]

06:31 craftyguy has quit [Ping timeout: 480 seconds]

06:33 craftyguy has joined #aarch64-laptops

06:43 jhovold has joined #aarch64-laptops

07:11 <jhovold> tstachecki-laptop: the efivars dependency is fixed here:

07:11 <jhovold> https://lore.kernel.org/lkml/20250423075143.11157-1-johan+linaro@kernel.org/

07:11 <jhovold> I mistakingly convinced myself we could do without the dt property when respinning v2...

07:12 <jhovold> and like steev said, you need to use UTC in windows if you want to dual boot (e.g. same as on x86)

07:15 <steev> (or tell linux that its set in local time)

07:16 <steev> e.g. timedatectl set-local-rtc 1 (for local) timedatecctl set-local-rtc 0 (utc)

07:19 tstachecki has joined #aarch64-laptops

07:19 Core5712 has quit [Read error: Connection reset by peer]

07:28 <jhovold> looks like charge control is supported also for x1e after all:

07:28 <jhovold> https://lore.kernel.org/lkml/025c297a-de13-49ee-81ea-2290df0f6843@oss.qualcomm.com/

07:29 <jhovold> kuruczgy[m]: sometimes you need to be persistent, perhaps we should ask again about sc8280xp too...

07:36 jglathe_volterra has quit [Remote host closed the connection]

07:39 chrisl has joined #aarch64-laptops

07:47 chrisl has quit [Ping timeout: 480 seconds]

08:19 <steev> they'd have to add it to the firmware and i haven't seen it yet :(

08:24 Core2417 has joined #aarch64-laptops

08:25 tstachecki has quit [Read error: Connection reset by peer]

08:25 Core2417 has quit [Read error: Connection reset by peer]

08:25 tstachecki has joined #aarch64-laptops

08:29 <jhovold> steev: it was already in the firmware for x1e, maybe it already is also for sc8280xp even if the initial reply when asked for bot was "no, it's not supported"

08:29 <jhovold> both*

08:47 M9names[m] has joined #aarch64-laptops

08:48 jhovold has quit [Quit: WeeChat 4.4.3]

08:48 jglathe_volterra has joined #aarch64-laptops

08:48 chrisl has joined #aarch64-laptops

08:56 chrisl has quit [Ping timeout: 480 seconds]

08:59 <kuruczgy_> jhovold: oh amazing. I was worried about being a bit annoying by asking another follow-up, but I guess a bit of persistence does pay off.

09:30 Core1026 has joined #aarch64-laptops

09:30 tstachecki has quit [Read error: Connection reset by peer]

09:42 chrisl has joined #aarch64-laptops

09:50 chrisl has quit [Ping timeout: 480 seconds]

10:35 tstachecki has joined #aarch64-laptops

10:35 Core1026 has quit [Read error: Connection reset by peer]

10:35 tstachecki has quit [Read error: Connection reset by peer]

10:35 tstachecki has joined #aarch64-laptops

10:50 chrisl has joined #aarch64-laptops

10:58 chrisl has quit [Ping timeout: 480 seconds]

11:20 <tstachecki> jhovold: ah okay using edefer, that's cleaner anyways thanks!

11:40 Core4964 has joined #aarch64-laptops

11:40 tstachecki has quit [Read error: Connection reset by peer]

11:41 Core4964 has quit [Read error: Connection reset by peer]

11:41 tstachecki has joined #aarch64-laptops

11:50 ungeskriptet_ has joined #aarch64-laptops

11:50 ungeskriptet has quit [Ping timeout: 480 seconds]

11:59 Core4335 has joined #aarch64-laptops

11:59 tstachecki has quit [Read error: Connection reset by peer]

12:02 tstachecki has joined #aarch64-laptops

12:07 Core4335 has quit [Ping timeout: 480 seconds]

12:08 ungeskriptet_ has quit [Remote host closed the connection]

12:09 ungeskriptet has joined #aarch64-laptops

12:19 tstachecki has quit [Read error: Connection reset by peer]

12:48 chrisl has joined #aarch64-laptops

12:56 chrisl has quit [Ping timeout: 480 seconds]

13:13 witcher01 has quit [Remote host closed the connection]

13:16 witcher01 has joined #aarch64-laptops

13:33 <spawacz> From time to time (say 1 of 3 runs) my x13s hangs completely when running wine. The relevenat part of journalctl -b -1: https://0x0.st/s/tQ6_mLdYWTjaWcxWmNz7Mg/83b3.txt What's the problem or solution?

13:45 iivanov has joined #aarch64-laptops

13:54 chrisl has joined #aarch64-laptops

14:02 chrisl has quit [Ping timeout: 480 seconds]

14:05 <robclark> spawacz: https://patchwork.freedesktop.org/series/143686/ should help.. mmu-500 has a tendency to get itself wedged when there are mmu faults otherwise, leaving gpu and gmu with no access to memory, in a kinda doom loop

15:06 akaWolf has quit [Ping timeout: 480 seconds]

16:07 iivanov has quit [Quit: Leaving...]

16:35 tstachecki has joined #aarch64-laptops

16:35 tstachecki has quit [Read error: Connection reset by peer]

16:38 chrisl has joined #aarch64-laptops

16:46 chrisl has quit [Ping timeout: 480 seconds]

16:53 xroumegue has joined #aarch64-laptops

16:54 xroumegue has quit []

16:54 xroumegue has joined #aarch64-laptops

17:34 <kuruczgy[m]> I think I have charge limiting working on the slim7x: https://github.com/kuruczgy/x1e-nixos-config/blob/2f5da0021095c6689f5dd037e9c638a4a5c3d10c/packages/lenovo-yoga-slim7x-batt-charge-limit.patch

17:34 <kuruczgy[m]> It's just https://lore.kernel.org/lkml/20250523-qcom_battmgr_update-v1-0-2bb6d4e0a56e@oss.qualcomm.com/ with a few extra lines

17:35 <kuruczgy[m]> (I think this should work on all x1e devices, and I would bet that it works on x13s too, though that isn't confirmed.)

17:37 <valpackett> nice

17:38 chrisl has joined #aarch64-laptops

17:46 chrisl has quit [Ping timeout: 480 seconds]

18:32 <steev> kuruczgy[m]: i'll give it a whirl on the x13s

18:32 <steev> i don't think the firmware supports it though on x13s

18:39 chrisl has joined #aarch64-laptops

18:48 chrisl has quit [Ping timeout: 480 seconds]

18:50 <steev> kuruczgy[m]: well, i do get the files, at least, how would i test that it works?

18:52 <steev> actually, gnome has an option to preserve battery health so i guess i check that

19:22 <kuruczgy[m]> steev: `echo 80 > /sys/class/power_supply/qcom-battmgr-bat/charge_control_end_threshold` (as root)

19:22 <kuruczgy[m]> And then observe whether the battery charges past 80%

19:23 <steev> gotta let it get down below 80% :D

19:35 <steev> assuming i read the patch right, it should just be the bat_props and psy_desc changes for sc8280xp

19:41 chrisl has joined #aarch64-laptops

19:49 chrisl has quit [Ping timeout: 480 seconds]

20:00 <kuruczgy[m]> Yes

20:01 <steev> echoing 80 into that file, it doesn't change (stays at 0), and alas, charging just went up to 82%

20:12 <kettenis> appears to work on the vivobook (with my own test code in OpenBSD)

20:12 <kettenis> let's see what happens on the x13s

20:20 <steev> that is the x13s :(

20:42 <kettenis> yeah, looks like the x13s firmware doesn't respond to the command

20:43 chrisl has joined #aarch64-laptops

20:51 chrisl has quit [Ping timeout: 480 seconds]

20:51 <kuruczgy[m]> steev: Sad :/

20:51 <kuruczgy[m]> You might want to respond here to ask about sc8280xp: https://lore.kernel.org/lkml/025c297a-de13-49ee-81ea-2290df0f6843@oss.qualcomm.com/#t

20:51 <kuruczgy[m]> Does it work on windows on the x13s?

20:53 <steev> windows does not offer the option in lenovo vantage, unfortunately

20:53 <steev> i'm double checking something though

20:55 <kuruczgy[m]> Also I get qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: unknown message 0x48 on dmesg because I did not add the code for handling the response, you might want to check if you ser something like that

21:07 <steev> that's what i was checking(ish?)

21:19 <steev> i do not see that message, but i'm doing one more check of things

21:29 <steev> speaking of power though... does anyone happen to know why the ac always reports as offline? e.g. plugging it in, and checking /sys/class/power_supply/qcom-battmgr-ac/online always reports 0

21:36 <steev> kuruczgy[m]: no glink messages amiss re: battery, but all the additions do not seem to help so i am assuming we would need new firmware on the X13s https://www.irccloud.com/pastebin/MV6iJuIM/

21:43 chrisl has joined #aarch64-laptops

21:51 chrisl has quit [Ping timeout: 480 seconds]

22:04 erebion_[m] has joined #aarch64-laptops

22:06 erebion_[m] has left #aarch64-laptops [User left]

22:07 erebion_[m] has joined #aarch64-laptops

22:18 <erebion> Are there patches to suspend for the X13s that are not yet upstreamed? Currently only longer suspend time is lacking for perfection, imho :)

22:21 <steev> i think konradybcio was working on something but i don't know

22:25 <steev> https://github.com/quic-kdybcio/linux if you wanna poke around at things

22:27 tstachecki has joined #aarch64-laptops

22:30 Core5327 has joined #aarch64-laptops

22:35 tstachecki has quit [Ping timeout: 480 seconds]

22:39 erebion_[m] has left #aarch64-laptops [User left]

22:45 xbjfk has quit [Ping timeout: 480 seconds]

22:45 xbjfk has joined #aarch64-laptops

22:45 chrisl has joined #aarch64-laptops

22:48 Core5327 has quit [Read error: Connection reset by peer]

22:48 tstachecki has joined #aarch64-laptops

22:53 chrisl has quit [Ping timeout: 480 seconds]

23:12 tstachecki has quit [Read error: Connection reset by peer]

23:14 <valpackett> HUUUUUH >>>> "Other Qualcomm platforms require more driver changes to restore the link state after wakeup." last commit there "better nvme hack"

23:14 <valpackett> that must be why i see nvme not coming back up from deep sleep

23:15 <steev> i can't say :) i don't know enough, i just know how to poke around and find things on github that aren't hidden but not announced either :D

23:16 <steev> also, got somewhat excited because lenovo's windows software had a power and battery update but sadly, still no enablement on X13s

23:27 mbuhl has quit [Remote host closed the connection]

23:29 mbuhl has joined #aarch64-laptops

23:45 chrisl has joined #aarch64-laptops

23:53 chrisl has quit [Ping timeout: 480 seconds]