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
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
chrisl has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
gkelly has quit [Remote host closed the connection]
<deathmist>
probably something Linux *could* support in the near future?
<deathmist>
surely something from those can be extracted and re-used
<JensGlathe[m]>
We're rich on non-info already
<JensGlathe[m]>
And even if you're willing to RE all that, somebody has to do it.
<deathmist>
on Linux side anyway this used to be a thing https://www.kernel.org/doc/html/v6.8/firmware-guide/acpi/method-customizing.html which sounds perfect for the job (could be brought back as a hack if nthing else), now then obviously the hard part is extracting the information from the PEPs you could feed into debugfs assuming kernel boots that far even without the methods
<deathmist>
what if https://wiki.debian.org/NdisWrapper but for ACPI PEP drivers? it's an idea if nothing else, probably anything else would be preferred
<JensGlathe[m]>
the wrapper would load the pep driver required? I remember ndiswrapper
hipboi has joined #aarch64-laptops
<deathmist>
I assume there's many PEP drivers for each board, I don't really know the full architecture but assuming they can be loaded via an "acpipepwrapper" they'd likely need to be "stimulated" somehow to get the included methods to be inserted/replaced from the binary through the available Linux kernel ACPI interfaces also exposed via e.g. configfs
<deathmist>
JensGlathe[m]: what does df -h | egrep '^Filesystem|efivars' say actually? maybe that could be used if some way to convert the from inside windows is found and have Linux just load them from there from that point forward
<deathmist>
idk if it even will have efivars mounted tho like usual x86_64 devices
<deathmist>
mount -t efivarfs none /sys/firmware/efi/efivars could alternatively get it going if not there by defalt but exposed by firmware for us
<deathmist>
ooh maybe full DSDT or similar can be dumped from inside windows where all of the PEP stuff is already going similar to /sys/firmware/fdt on Linux device-tree based platforms
<deathmist>
or are the PEP stuff excluded or unusable still due to some othe reason?
<JensGlathe[m]>
Export of dsdt is same from Windows and from Linux
<deathmist>
hm so I really wonder how does stuff calling the functions suddenly get redirected to the PEP stuff in windows then, I guess it only happens when you call the methods themselves in some windows API and they may not be explicitly exposed via any windows API to us directly (especially in DSDT form) which would be unfortunate..
<deathmist>
this is really not a great start for other OSes on WoA machines, microsoft could've gone the route of programatically allow driver vendors to "generate extra DSDT" which is then loaded in on runtime, but instead they've seemingly made their ACPI method handler call a windows driver instead of whatever DSDT may specify
<deathmist>
a great rabbit hole for sure I've stumbled into by getting one of these machines even if device-tree based stuff does technically work..
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
X14 dt is pretty usable, could be worse.
chrisl has quit [Ping timeout: 480 seconds]
<Jasper[m]>
@deathmist they've looked at this 8 years ago when Windows on Snapdragon devices started coming out. That's where the aarch64-laptops repo comes from. Issue is that it turned out to be a bigger hassle as far as full compat goes, even _just_ USB, display, nvme and kbm turned out to be hard
<macc24>
why would anyone use acpi over dt on arm64?
<deathmist>
ideally it would've been already there in firmware instead of having to write the device-tree, and any OS supporting modern ACPI could "just boot", assuming drivers exist
<Jasper[m]>
macc24, Shipped from oem, somewhat standardised'ish
<macc24>
somewhat...
<Jasper[m]>
Just not on WoS obviously
<deathmist>
but since it's not just in firmware in this case with PEPs etc it seems to be more of a hassle than it's worth even if the methods are extracted from PEPs and stored in efivars or something somehow..
<Jasper[m]>
macc24: You can wonder why x86 hasn't switched to DT
<JensGlathe[m]>
Seen something odd on a surface 11 efi dump. Looked like Device tree, one file by node
<macc24>
i mean... there's devicetrees in the efi firmware
<JensGlathe[m]>
Yeah they are interesting but only enough to bring up efi os and gunyah
<deathmist>
but are they *fully complete* like ACPI on general x86_64 machines anyway is? theoretically firmware updates could be done but Linux API keeps changing so DT would have to be updated from time to time
<JensGlathe[m]>
No they appear to be not
<Jasper[m]>
deathmist: No, that's why it won't work any time soon
<Jasper[m]>
Oh, wait, you're talking about the DT. Nevrrmind
<Jasper[m]>
*Nevermind
<deathmist>
yeah ig I worded that all weird, DT in firmware wouldn't really work since it's kinda Linux specific and even in Linux it keeps changing constantly and would require firmware upgrades often to keep booting not to even speak of backward compat etc
<deathmist>
oh well, dealing with DT stuff is just not the best as it needs the dts files written per-device instead of using pre-existing complete ACPI tables from firmware and have it all "just work" assuming drivers themselves exist etc, too bad it didn't end up working out even in the early days where I assume PEP drivers weren't in the way... one can hope things improve
<Jasper[m]>
PEP was a problem before, iirc they used the same system on the RT devices before Windows on Snapdragon
<deathmist>
don't get me wrong from a Linux kernel hacker's perspective is awesome and a great simple format to do what complicated ACPI tables do, but they do solve a problem which doesn't exist for consumers booting practically any random x86_64 computers
<Jasper[m]>
The existence of chromebooks, phones with downstream sources and devboards has made WoS devices running Linux at least possible and workable as a daily.
<Jasper[m]>
People have been working on options to make a more generic boot environment possible, it's gained more steam now pretty good performance is possible
* macc24
is a big fan of depthcharge
davidinux has joined #aarch64-laptops
* travmurav[m]
mumbles something about billions of platform/fixup drivers for every single laptop in linux because vendor apci is never actually right
chrisl has joined #aarch64-laptops
<travmurav[m]>
but also I'm pretty sure dt is supposed to be both ways compatible assuming you're actually using upstream documented bindings
<travmurav[m]>
but eh I guess the real question is more like "who has the time to implement all the acpi stuff"
<travmurav[m]>
and for dt we already have half of the world done due to mobile platforms
janrinze has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Quit: WeeChat 4.3.1]
<erebion[m]>
My X13s now just boots into a boot menu and I cannot boot anything. Tested my SSD with an adapter and another machine and it is fine. WTF is going on?
<erebion[m]>
Anyone here seen this?
<macc24>
secure boot?
xroumegue has quit [Ping timeout: 480 seconds]
<erebion[m]>
Nope.
<erebion[m]>
It also does not want to boot a known working Debian arm64 from USB
<erebion[m]>
I just re-set the BIOS settings and disabled Secure Boot again and now it wants to boot again
<erebion[m]>
Maybe the BIOS settings got corrupted during suspend somehow..?
<travmurav[m]>
perhaps some stuck efivar telling it to go to the setup mode or something like that?
<travmurav[m]>
I guess can't know now after it was reset xD
<erebion[m]>
No idea, I just know last night I put it into suspend as always and after sleeping I was pressing the power button to wake it up and instead got the Lenovo logo.
hipboi has quit [Quit: hipboi]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<steev>
i have been fortunate enough to not have hit that here
chrisl has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov_ has quit [Read error: Connection reset by peer]
iivanov has quit [Remote host closed the connection]
<freekurt[m]>
Unplugging and repluging the monitor cable works, but it is annoying to have to do all the time.
<freekurt[m]>
This is on Ubuntu with the 6.11.0.9-generic kernel.
echanude has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Frankly, I avoid this situation. I know dp altmode is shot (at least with msm). It is also a no-documentation situation. Even if you want to fix this you need the specification and testing equipment, and lots of dev time from capable people. A money question in the end.
<freekurt[m]>
How do you avoid the situation?
<JensGlathe[m]>
Using dev kits as desktops with external screen (one)
<JensGlathe[m]>
Laptops as the mobile devices they are, without a screen
<JensGlathe[m]>
Occasionally testing a bit if I can debug dp altmode a little more, but mostly nope
janrinze has joined #aarch64-laptops
<JensGlathe[m]>
I mean, I invested in a display with type-c port just to test it without these pesky adapters that mostly don't work either, so there's that
<JensGlathe[m]>
the display is nice, though
echanude has joined #aarch64-laptops
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<macc24>
<JensGlathe[m]> "I mean, I invested in a display..." <- how is it different from a usb-c to a displayport cable?
echanude has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
I didn't know, just assumed that it would be one chip less to worry about. This link training appears to be some tricky business. And now we have the retimers in the x1e hw, which need to be configured and also controlled for link training to succeed.
pbsds is now known as Guest8861
pbsds has joined #aarch64-laptops
<JensGlathe[m]>
And frankly I didn't know they did such odd things like these type-c to dp cables. And from what I read the don't work either
<macc24>
i mean... i have a type-c to dp cable and it worked with every single device with working type-c display output, except x1e78100 on linux
<freekurt[m]>
Jens: do you use the windows dev kit 2023, then?
<JensGlathe[m]>
yes
Guest8861 has quit [Ping timeout: 480 seconds]
<freekurt[m]>
can you connect two monitors to that, or just one?
<JensGlathe[m]>
one via minidp
iivanov_ has joined #aarch64-laptops
<JensGlathe[m]>
You can try type-c, but this worked not really reliably (6.6..6.9), after that I didn't bother. And with type-c to hdmi adapter it was a mixed bag, now its just not really working.
<robclark>
I've used type-c to dp cable on a bunch of other qc things... I think the issue is just that some of the type-c+dp stuff (mostly( external to the display controller is still WIP
iivanov_ has quit [Remote host closed the connection]
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<steev>
alt mode stuff is being worked on, and i saw lumag post some dp patches recently as well to simplify things, but don't know what the overall status is
<freekurt[m]>
what dock do you use erebion 🏳️🌈♾ ?
<steveej[m]>
mynery: i'm partially maintaining a nixos module for the x13s: https://codeberg.org/steveej/nixos-x13s let me know if you have any questions about it
alexeymin has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
cyrinux has quit []
cyrinux has joined #aarch64-laptops
<steev>
don't forget that the matrix room is bridged with irc when doing replies