robclark 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
<colemickens> oh whoa, slick
<colemickens> some kernel, dtb and firmware and cross my fingers?
<colemickens> if so, I'm very very close to having an image to take to bestbuy and test haha
<robclark> you'll need to disable secure boot, ofc.. not sure what bbuy will let you get away with
<HdkR> Got a box!
<robclark> ohh, first x1d devbox on #aarch64-laptops?
<HdkR> Well, got one ordered :P
<HdkR> Arrow being a nightmare
<robclark> heh
<robclark> my guess would be the devbox is closely related to crd, so maybe not too hard to hack up dts for
<HdkR> I'm hoping
<robclark> at this point, my yoga slim is working well enough that I'll probably pass on the devbox
<robclark> but if devbox shipped sooner it would have been a different story
<HdkR> The 4.3Ghz boost is something I want to test
<HdkR> and the dev box is better than a laptop sitting on my desk :D
<steev> robclark: it should be part of 6.11
<robclark> yeah, the boost is tempting... but not having to carry around an external monitor is nice too.. my main interest in the dev box was uncertainty about how quickly dts would come together for the other laptops, but that has turned out to be not so much of a problem
<steev> i bet konrad has some secretsauce aml -> dts converter :P
<HdkR> I assume there aren't any random downstream thunderbolt patches so I can yeet my Orin setup out a window yet?
<colemickens> that's actually another question I've been wondering about. Someone told me these laptops couldn't support an egpu, but I thought USB4/Thunderbolt meant exposed pcie lanes, and thus... should be possible?
<HdkR> colemickens: Apple Silicon is a prime example of having Thunderbolt but not being able to support eGPUs
<HdkR> Hardware limitation there
<HdkR> There have been whispers of eGPU support on X1E, but nothing conclusive to back up those claims
<Eighth_Doctor> but at least Apple Silicon will let you run VMs :(
<Eighth_Doctor> * run VMs,, * as the Qualcomm SoCs don't... :(
<robclark> I guess at least partially a sw problem? Ie. if you don't have KMD recompiled for arm64 then all bets are off
<colemickens> I see, clearly I don't understand TB4 well then. I didn't realize you could support TB4 (supposedly?) but somehow miss something than an egpu would need.
<robclark> Eighth_Doctor: apparently slbounce works.. but the more accureate statement is that qcom soc's don't allow VMs with kvm
<robclark> (modulo slbounce)
<Eighth_Doctor> yeah
<Eighth_Doctor> which tbh sucks
<robclark> I guess it will be resolved in time
<Eighth_Doctor> you think so?
<Eighth_Doctor> how?
<robclark> either slbounce + we figure out how to get things that don't work with slbounce working, or upstream support for gunya
<robclark> anyways, it has taken apple Si a long time to get upstream support.. so the bar is low ;-)
<Eighth_Doctor> that's not for a lack of trying
<Eighth_Doctor> it seems like their patches get stuck rather than getting reviewed
<robclark> sure, not knocking the work on apple stuff (although apple makes it harder by having a slightly less normal interpretation of the arm arch)
<robclark> but this kind of change takes time
<robclark> (which makes the "I'm waiting for riscv crowd" pretty hilarious :-P)
<Eighth_Doctor> is there even a normal arm arch?
<Eighth_Doctor> like the qualcomm stuff violates the SBSA and UEFI spec
<Eighth_Doctor> even the WoA devices don't conform
<Eighth_Doctor> and Windows is usually quite firm on that conformance
<HdkR> I'm hoping eGPU will work over Thunderbolt, otherwise I'm going to be a very sad lad once TB comes online
<Eighth_Doctor> it won't
<Eighth_Doctor> it's physically not possible
<HdkR> How so?
<Eighth_Doctor> lemme get the explaination from marcan for it
<HdkR> Oh no
<HdkR> Not on Apple SI
<Eighth_Doctor> but basically the design on the board is wrong
<HdkR> I mean on X1E
<HdkR> I know Apple SI is boned for eGPU over TB
<Eighth_Doctor> oh on X1E it's dependent on the board design :)
<HdkR> Well, I guess Apple SI can't even do GPU over PCIe on Mac Pro, so pretty funny there
<Eighth_Doctor> so who knows
<Eighth_Doctor> it's all board design stuff... the controllers themselves can do it, IIRC
<Eighth_Doctor> just everything else can't
<robclark> Eighth_Doctor: well main thing is windows moved the bar when it comes to ACPI with PEP.. which linux doesn't have a good answer for.. arm server stuff is pretty normal as far as ACPI/UEFI (but that is a easier situation, the limitations of ACPI aren't as big a deal there)
<Eighth_Doctor> I kind of wish we didn't have DeviceTree :(
<Eighth_Doctor> from the distro side, DT is pretty awful
<Eighth_Doctor> I was incredibly sad when I found out Linux can't boot UEFI+ACPI even on WoA devices
<robclark> I've a mixed view on that.. it is cleaner from kernel perspective, but it doesn't let us decouple kernel dev cycle from hw dev cycle
<robclark> I'm not sure what the long term solution on that is.. current approach isn't scaleable, I don't think
<robclark> so we probably need to revisit acpi support.. but idk
<Eighth_Doctor> it's already burning out distro people in the arm space
<Eighth_Doctor> tbh, I'm barely holding things together with the arm stuff I do now
<Eighth_Doctor> and risc-v scares me on this because every problem we have with arm is worse there
<robclark> maybe the right approach is just something that runs pre-kernel like DtbLoader that knows how to pick the right dtb to load, so things appear "normal" to distro.. the downside will be some time lag btwn hw avail and dtb (but that has gone pretty quickly so far with a few x1e laptops)
<robclark> and defn yeah re: standardization on r-v
<Eighth_Doctor> well, that means the DT format needs to be decoupled from Linux
<Eighth_Doctor> the biggest flaw with DT is that it's too coupled to Linux and changes to DT and Linux happen at the same time
<robclark> it already is.. technically... it is used by u-boot, rtso, the dsp stuff on qcom
<Eighth_Doctor> yeah, but no
<colemickens> "technically" pulling weight there, to my understanding
<Eighth_Doctor> DTs have to be individually synced to all of them
<Eighth_Doctor> and they are not exactly the same
<Eighth_Doctor> which makes it even more painful
<robclark> that isn't quite what you are getting at.. it is that dtb needs to be available when hw is avail (which is the actual problem when OEMs aren't caring about dtb)
<Eighth_Doctor> well, if they did, they'd be using ACPI
<robclark> if windows were using dtb it wouldn't be so much of a problem
<Eighth_Doctor> honestly, I'm happy they don't
<robclark> it's not really an acpi vs dtb issue.. it's just an issue that linux is second consideration
<Eighth_Doctor> I cross my fingers that they'll push arm machines to be more PC-like
<robclark> dtb works well on chromebooks ;-)
<Eighth_Doctor> who cares about linux on arm desktops/laptops officially?
<robclark> it's not an arm problem.. it's a problem that pm is less sophisticated on x86 things where acpi was developed
<Eighth_Doctor> outside of Asahi Linux, I don't really know of anyone who does
<Eighth_Doctor> sure, but acpi does a lot more than pm... it's a big part of why plug-and-play works well
<Eighth_Doctor> dtb is the whole thing done backwards
<robclark> there is a bit of difference in philosophy
<robclark> it would be nice if we could have the best of both without the worst of both
<Eighth_Doctor> well, sure
<Eighth_Doctor> but that would require cooperation on a level we have not seen since the 90s
<robclark> yeah, idk what the long term answer is
<Eighth_Doctor> and in an era where linux drivers are dominated by vendors rather than users, and hobbyist/community developers aren't important anymore... I don't know where it would come from
clee_ is now known as clee
* Eighth_Doctor sobs at his kernel tree of 1k+ out of tree commits
Son_Goku has joined #aarch64-laptops
<robclark> qcom is getting reasonably good at not having massive vendor branch, tbh.. ofc that only helps the core SoC support, not the board level support.. but things are at least moving in the right direction, things were much more dire 5yrs ago ;-)
<Eighth_Doctor> yes, and way worse 12 years ago when it was my job :)
<robclark> hmm, situation on arm was not great 12yrs ago.. I was there
<Eighth_Doctor> being involved in the early stuff is what put me off arm for a long time
<Eighth_Doctor> tbh, if it weren't for asahi linux, I'd have a 100% negative outlook on linux arm today
<Eighth_Doctor> that project showed me it's possible to have an arm pc that's actually good and behaves almost completely normally with linux
<robclark> I mean apple's hw is a lot more non-standard.. and also has the dtb problem ;-)
<robclark> it's only advantage is that there are fewer dts files to write
<clee> well, and that it's really damn good hardware
<Eighth_Doctor> well, no, the thing that made it different is that vendor politics didn't prevent it from being good
<robclark> hmm, or more like they had vertical OS integration so they were able to make choices that made sense for macos
<Eighth_Doctor> so much of linux arm support is kind of bad because it's hamstrung by people that just don't really want to put in the effort
<Eighth_Doctor> to be fair, x86 suffers this way too nowadays
<Eighth_Doctor> even after 30 years, we still don't have power management as good as Windows for x86
<Eighth_Doctor> it was a different experience dealing with people who just wanted everything to work
<robclark> tbh arm is taking over the data center.. so not really an arm or linux problem.. just that acpi and linux acpi support is insufficient ;-)
<robclark> *for laptops
<Eighth_Doctor> back in the day, I dealt with vendor BSP people a lot... and man they really couldn't care less about the quality of the stuff they gave you
<robclark> sure
<Eighth_Doctor> and there's still slivers of that in upstream linux arm stuff now
<clee> is there any updated page showing what's included X1E-wise in the 6.10 release kernel, and what's still yet to be merged?
<robclark> android hasn't really pushed things in a good direction... and that gives people a unfair negative perception
<Eighth_Doctor> broadcom wifi drivers suck because community efforts to fix them are basically ignored by the maintainers
<Eighth_Doctor> arm people in charge of the cpu support stuff argue about things that don't matter for patches that enable features
<robclark> clee: for stuff I know about, gpu support is landing in 6.11.. I guess there are other things still pending.. you proably want to use integration branch until 6.11 or 6.12
<Eighth_Doctor> so much crap that prevents us from being better
<clee> robclark: I was thinking it'd be nice to try booting a newer kernel and see if I can get USB working on my Yoga
<Eighth_Doctor> and yeah, android really has not helped
<Eighth_Doctor> google's gki did not make that better
<robclark> clee: so yoga dts will be I think v6.12?
<robclark> yeah, gki is kinda dumb.. but otoh android didn't have a better alternative because too much of kernel they didn't control
<Eighth_Doctor> well they don't do a great job of leading by example either for pixel
<Eighth_Doctor> it seems like they stopped upstreaming pixel devices after the 6
<Eighth_Doctor> but after kind of being part of the asahi upstream efforts, I wonder if it's not entirely their fault
<Eighth_Doctor> it's been hard to get stuff upstreamed
<robclark> I mean, it is a bit ironic that they dropped qc just as qc started getting good at upstreaming things
<robclark> (for pixel)
<robclark> but it will be interesting to see how gki plays out.. I think it is too young at this point, and my experience at rh with a slightly similar thing was that it gets harder as time goes on
<Eighth_Doctor> rh?
<robclark> redhat
<robclark> still, I don't see how android could have done better without a completely different distribution model from the start
<Eighth_Doctor> yes, I figured that out, I didn't realize you were at rh before goog
<Eighth_Doctor> tbh, I think GKI will become too hard for them by the end of the decade
<robclark> I tend to agree
<robclark> that was my experience with rhel kernel work
<Eighth_Doctor> the problem GKI has is much worse than RHEL... many more trees and many more permutations to deal with than RH ever had
<Eighth_Doctor> at this point, I think GKI and RHEL have the same number of parallel maintained trees, and GKI not has been around for anywhere close to the timeframe RHEL has
<Eighth_Doctor> that's pretty bonkers
<robclark> so GKI only provides a stable ABI for the life of the kernel branch.. which makes it easier.. but it adds dependency on vendors to update there out of tree modules.. which is where I am skeptical
<Eighth_Doctor> yes
<Eighth_Doctor> well, accepting out of tree kernel modules basically breaks the model
<robclark> they also apparently included drivers/gpu/drm in gki, which rh wisely avoided
<robclark> yeah
<Eighth_Doctor> the only reason RHEL doesn't fall on its sword is that they don't accept out of tree code generally
<robclark> but android already committed themselves to this problem
<robclark> ie. vs CrOS which controls the sw distribution
<Eighth_Doctor> well, CrOS is androidifying
<Eighth_Doctor> so much for that
<robclark> so a business model problem.. which you aren't going to solve with sw solution
<Eighth_Doctor> can't solve people with tech :P
<robclark> well, we'll see.. CrOS still controls the sw distribution
<robclark> so possible to avoid the problems
<Eighth_Doctor> hah
<Eighth_Doctor> once GKI is used by CrOS, it's game over
<Eighth_Doctor> replacing bluez with the android stack was a pretty big signal
<Eighth_Doctor> and ending lacros was another
<robclark> idk if that is given yet.. there are different opinions
<Eighth_Doctor> oh sure
<Eighth_Doctor> we'll see how it goes
<Eighth_Doctor> but seeing lacros end was a big nail to me
<robclark> tbh I think lacros was the wrong approach.. to me the real big question is how we approach kernel wrt 10yr support window
<Eighth_Doctor> lacros itself isn't why I think that
<robclark> CrOS compositor wasn't great.. and there are some aspects to android userspace which are better (at least for what CrOS needs)
<robclark> but yeah, gki could make it go badly
<Eighth_Doctor> lacros might have been bad, I don't know, but it signifies a very big shift in strategy
<Eighth_Doctor> to me, it says "we're done with our sw layer centric model"
<Eighth_Doctor> ie. the end of composition in cros
<Eighth_Doctor> this is the big difference to android in my view
<robclark> business model remains the same.. sw is still delivered from goog... that is a pretty important detail
<robclark> and that makes it a night/day diff from "android"
<Eighth_Doctor> maybe? it may shift to a "OEM-integrate CrOS" model similar to Android
<Eighth_Doctor> if GKI gets used for CrOS, I would expect that shift
<robclark> that is the detail the devil resides in
<Eighth_Doctor> the reason I believe that is that GKI is not valuable outside of that
<Eighth_Doctor> GKI is ABI-stablization for OOT modules
<Eighth_Doctor> you don't need it if you aren't doing that
<robclark> like I said, that is still up in the air.. there are various proposals
<robclark> our needs are somewhat different from "traditional android"
<robclark> esp since we have already committed to 10yr updates
<Eighth_Doctor> oh for sure
<Eighth_Doctor> though yeah, I looked at Exo recently and... ehhh
<Eighth_Doctor> use kwin, it's better :P
<robclark> tbh.. I'd like a SF model better, just push all the layers to the compositor and let it figure out how to balance btwn gpu and hw overlay (although weston is at least close to that)
<robclark> qcom display hw is a bit too flexible, g-s has had issues with this.. idk about kwin... but android has done well with it for years
<Eighth_Doctor> kwin is much better than mutter :)
<Eighth_Doctor> (mutter is the gnome compositor)
<Eighth_Doctor> iirc, the mercedes-benz folks use kwin in their cars quite effectively
<robclark> hopefully on things other than intel? CrOS compositor issues are entirely baked-in intelisms
<Eighth_Doctor> all arm
<Eighth_Doctor> and I can assure you kwin works great on multiple arches because KDE is the Fedora Asahi Remix flagship :)
<robclark> what I've heard from asahi folks on display compositing.. well it sounds like apples display controller is a bit limited
<robclark> but if it works on other arm things maybe it is decent.. idk
<Eighth_Doctor> unfortunately I only have an M1 MBP
<Eighth_Doctor> I don't have any other working arm devices
<Eighth_Doctor> but I'm very confident in the quality of kwin
<robclark> for a laptop, it probably matters less.. screen is a big power consumer, so who cares.. and for auto, power doesn't matter.. for a phone the situation is different
<Eighth_Doctor> well plasma mobile is a thing, aimed for phones
<Eighth_Doctor> and postmarketos (and future fedora kde mobile) use it pretty well
<Eighth_Doctor> and it uses kwin, unlike gnome mobile phosh which does not use mutter
<Eighth_Doctor> and you can build kwin without x11 support at all if you wish
<Eighth_Doctor> pure wayland
<robclark> if kwin can use atomic properly, that would be nice (thinking about display features we haven't landed upstream yet, like wideplane and virtual planes)
<steev> Eighth_Doctor: why the hell do you have 1k out of tree commits? why aren't they being submitted?
<steev> the rest of the convo is tldr :P (i did i just don't have any other comments)
<Eighth_Doctor> steev: because getting anyone to review asahi linux stuff is torturous
<robclark> hey, qcom _used_ to have 1+ million loc of dowstream patches :-P
<steev> that's rough
<Eighth_Doctor> robclark: you're referring to atomic modesetting right?
<steev> the x13s is only 83 on top of 6.10
<steev> at least, for my tree
<Eighth_Doctor> steev: I'm carrying a patchset that rewrites the broadcom wifi driver :(
<steev> oh?
<Eighth_Doctor> that is not upstream because the broadcom folks are ignoring patch submissions
<steev> this piques my interest
<steev> link to it on the ml? i'm assusming since you mentioned broadcom are ignoring it one exists :D
<Eighth_Doctor> i'd have to dig it up again
<robclark> yeah, qc hw is fun.. in that sometimes you can use a single SSPP for multiple planes and sometimes you need multiple SSPP for a single plane.. which really requires userspace to use atomic kms properly
<Eighth_Doctor> it was almost two years ago
<Eighth_Doctor> steev: here's the current version of the patch set:
<Eighth_Doctor> it's not a total rewrite, but large chunks were completely reworked
<Eighth_Doctor> robclark: kwin supports atomic modesetting, I think it might be the only one that does of the "desktop" wayland compositors
<Eighth_Doctor> I know this because it trips up a few GPUs
<steev> Eighth_Doctor: as someone who works quite a bit with rpis.... the broadcom driver needs it
<Eighth_Doctor> oh I know
<steev> thus piquing my interest. i'll try to find some time over the coming weeks to look through
<Eighth_Doctor> that'd be great
<Eighth_Doctor> robclark: kwin 6.2 is planned to support tearing with atomic modesetting: https://invent.kde.org/plasma/kwin/-/merge_requests/4800
<Eighth_Doctor> and full color management is implemented already
<Eighth_Doctor> just waiting on w-p stabilization to unguard it
<robclark> tbh async atomic commits are a pain to emulate... like legacy cursor..
<Eighth_Doctor> the kwin folks are pretty accessible in #kwin:kde.org
<robclark> it isn't a common thing for non-desktop hw to support
<robclark> just make sure kwin devs have some x1e hw ;-)
<Eighth_Doctor> well, sure
<Eighth_Doctor> I'd also like to support fedora kde on it too
<Eighth_Doctor> but acquiring hardware is not easy :)
<Eighth_Doctor> but getting past the funding part, I don't know what to get yet
<Eighth_Doctor> I don't know where the x1e platforms line up on linux support
<Eighth_Doctor> the SoC is not enough... dtbs and other drivers need to be in too
<Eighth_Doctor> or at least close to in
albsen[m] has quit [Write error: connection closed]
sera[m] has quit [Remote host closed the connection]
colemickens has quit [Write error: connection closed]
travmurav[m] has quit [Write error: connection closed]
z3ntu has quit [Write error: connection closed]
jenneron[m] has quit [Write error: connection closed]
Eighth_Doctor has quit [Write error: connection closed]
qzed has quit [Write error: connection closed]
LucasTreffenstdt[m] has quit [Write error: connection closed]
KieranBingham[m] has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
frozen_cheese[m] has quit [Remote host closed the connection]
konradybcio has quit [Write error: connection closed]
\[m] has quit [Write error: connection closed]
Segfault[m] has quit [Write error: connection closed]
Nios34[m] has quit [Write error: connection closed]
JensGlathe[m] has quit [Write error: connection closed]
Jasper[m] has quit [Remote host closed the connection]
<steev> the work is definitely in progress and progressing
<steev> https://github.com/jhovold/linux/tree/wip/x1e80100-6.10-rc7-gpu-pcie is one of the more recent trees of things, abelvesa also has a tree (on git.codelinaro.org though i think)
<robclark> yoga slim is usable.. missing battery status (I guess missing EC?) and a few things... asus vivobook seems in a similar state. I guess either of those would be good starting point? But as steev mentioned things are moving fast
<steev> isn't the battery status because of the le32 thing or something?
<robclark> umm, maybe? Ask me about gpu or maybe display things instead of board bringup? :-P
<robclark> seems plausible
<steev> that one might not be related though
<robclark> I've not had a chance to rebase on abelvesa's -next branch for a few days so my state of things might already be outdated :-P
<steev> that's fair
<steev> i don't have an x1e so i haven't at all :)
<steev> but it does look like johan's keeping the 8280xp stuff in his x1e branches, so i might just start doing them too, cuz why not
<steev> i've long dreamt of combining the c630/flex5g/thinkpad stuff together and just have 1 kernel for all 3 of my devices, for stuff that's still outstanding
sera[m] has joined #aarch64-laptops
<sera[m]> the battery status works fine for me on the yoga with an equivalent patch to the one on the list (just ignoring the extra data at the end of the battery payload)
<sera[m]> main thing that doesn't work for me is things relying on the pmic glink driver (ex. dp altmode).. seems like the intent request on the remoteproc glink edge doesn't work, but I don't know enough to root cause any further
mani_s has quit [resistance.oftc.net larich.oftc.net]
bryanodonoghue has quit [resistance.oftc.net larich.oftc.net]
robher has quit [resistance.oftc.net larich.oftc.net]
checkfoc_us has quit [resistance.oftc.net larich.oftc.net]
leiflindholm has quit [resistance.oftc.net larich.oftc.net]
Melody91 has quit [resistance.oftc.net larich.oftc.net]
pundir has quit [resistance.oftc.net larich.oftc.net]
ardb has quit [resistance.oftc.net larich.oftc.net]
sibis has quit [resistance.oftc.net larich.oftc.net]
jhugo has quit [resistance.oftc.net larich.oftc.net]
steev has quit [resistance.oftc.net larich.oftc.net]
jonmasters has quit [resistance.oftc.net larich.oftc.net]
clee has quit [resistance.oftc.net larich.oftc.net]
lool has quit [resistance.oftc.net larich.oftc.net]
checkfoc_us has joined #aarch64-laptops
mani_s has joined #aarch64-laptops
Son_Goku has joined #aarch64-laptops
bryanodonoghue has joined #aarch64-laptops
robher has joined #aarch64-laptops
ardb has joined #aarch64-laptops
Melody91 has joined #aarch64-laptops
pundir has joined #aarch64-laptops
jhugo has joined #aarch64-laptops
leiflindholm has joined #aarch64-laptops
steev has joined #aarch64-laptops
jonmasters has joined #aarch64-laptops
sibis has joined #aarch64-laptops
clee has joined #aarch64-laptops
jgowdy has joined #aarch64-laptops
apalos has joined #aarch64-laptops
craftyguy has joined #aarch64-laptops
lool has joined #aarch64-laptops
systwi has joined #aarch64-laptops
mjeanson has joined #aarch64-laptops
jgowdy has quit [resistance.oftc.net larich.oftc.net]
craftyguy has quit [resistance.oftc.net larich.oftc.net]
apalos has quit [resistance.oftc.net larich.oftc.net]
systwi has quit [resistance.oftc.net larich.oftc.net]
mjeanson has quit [resistance.oftc.net larich.oftc.net]
Son_Goku has quit [resistance.oftc.net larich.oftc.net]
shawnguo has quit [resistance.oftc.net weber.oftc.net]
Lucanis has quit [resistance.oftc.net weber.oftc.net]
echanude has quit [resistance.oftc.net weber.oftc.net]
adamcstephens has quit [resistance.oftc.net weber.oftc.net]
sgerhold has quit [resistance.oftc.net weber.oftc.net]
alx___ has quit [resistance.oftc.net weber.oftc.net]
dianders has quit [resistance.oftc.net weber.oftc.net]
_alice has quit [resistance.oftc.net weber.oftc.net]
CosmicPenguin has quit [resistance.oftc.net weber.oftc.net]
zdykstra has quit [resistance.oftc.net weber.oftc.net]
broonie has quit [resistance.oftc.net weber.oftc.net]
jbowen has quit [resistance.oftc.net weber.oftc.net]
KhazAkar has quit [resistance.oftc.net weber.oftc.net]
einar has quit [resistance.oftc.net weber.oftc.net]
rfs613 has quit [resistance.oftc.net weber.oftc.net]
spawacz has quit [resistance.oftc.net weber.oftc.net]
enyalios has quit [resistance.oftc.net weber.oftc.net]
jlinton has quit [resistance.oftc.net weber.oftc.net]
nios34 has quit [resistance.oftc.net weber.oftc.net]
ldts has quit [resistance.oftc.net weber.oftc.net]
\\ has quit [resistance.oftc.net weber.oftc.net]
vkoul has quit [resistance.oftc.net weber.oftc.net]
lumag has quit [resistance.oftc.net weber.oftc.net]
dgilmore has quit [resistance.oftc.net weber.oftc.net]
ndec has quit [resistance.oftc.net weber.oftc.net]
olv has quit [resistance.oftc.net weber.oftc.net]
abby has quit [resistance.oftc.net weber.oftc.net]
bamse has quit [resistance.oftc.net weber.oftc.net]
arnd has quit [resistance.oftc.net weber.oftc.net]
gwolf has quit [resistance.oftc.net weber.oftc.net]
lvrp16_ has quit [resistance.oftc.net weber.oftc.net]
eric_engestrom has quit [resistance.oftc.net weber.oftc.net]
sskras has quit [resistance.oftc.net weber.oftc.net]
gabertron has quit [resistance.oftc.net weber.oftc.net]
robclark has quit [resistance.oftc.net weber.oftc.net]
echanude has joined #aarch64-laptops
shawnguo has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
sgerhold has joined #aarch64-laptops
adamcstephens has joined #aarch64-laptops
_alice has joined #aarch64-laptops
broonie has joined #aarch64-laptops
zdykstra has joined #aarch64-laptops
CosmicPenguin has joined #aarch64-laptops
KhazAkar has joined #aarch64-laptops
einar has joined #aarch64-laptops
rfs613 has joined #aarch64-laptops
spawacz has joined #aarch64-laptops
ldts has joined #aarch64-laptops
enyalios has joined #aarch64-laptops
dgilmore has joined #aarch64-laptops
ndec has joined #aarch64-laptops
arnd has joined #aarch64-laptops
olv has joined #aarch64-laptops
lvrp16_ has joined #aarch64-laptops
robclark has joined #aarch64-laptops
gwolf has joined #aarch64-laptops
\\ has joined #aarch64-laptops
nios34 has joined #aarch64-laptops
bamse has joined #aarch64-laptops
gabertron has joined #aarch64-laptops
dianders has joined #aarch64-laptops
alx___ has joined #aarch64-laptops
jbowen has joined #aarch64-laptops
lumag has joined #aarch64-laptops
vkoul has joined #aarch64-laptops
eric_engestrom has joined #aarch64-laptops
sskras has joined #aarch64-laptops
abby has joined #aarch64-laptops
jlinton has joined #aarch64-laptops
systwi has quit [Remote host closed the connection]
hightower2 has quit [charon.oftc.net coulomb.oftc.net]
ellyq has quit [charon.oftc.net coulomb.oftc.net]
kalebris has quit [charon.oftc.net coulomb.oftc.net]
bluerise has quit [charon.oftc.net coulomb.oftc.net]
martiert has quit [charon.oftc.net coulomb.oftc.net]
jbru has quit [charon.oftc.net coulomb.oftc.net]
akaWolf has quit [charon.oftc.net coulomb.oftc.net]
xroumegue has quit [charon.oftc.net coulomb.oftc.net]
Mary has quit [charon.oftc.net coulomb.oftc.net]
tobhe_ has quit [charon.oftc.net coulomb.oftc.net]
alpernebbi has quit [charon.oftc.net coulomb.oftc.net]
Libre___ has quit [charon.oftc.net coulomb.oftc.net]
krei-se has quit [charon.oftc.net coulomb.oftc.net]
Kelsar has quit [charon.oftc.net coulomb.oftc.net]
fossdd has quit [charon.oftc.net coulomb.oftc.net]
bluerise has joined #aarch64-laptops
xroumegue has joined #aarch64-laptops
ellyq has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
Kelsar has joined #aarch64-laptops
martiert has joined #aarch64-laptops
fossdd has joined #aarch64-laptops
Mary has joined #aarch64-laptops
jbru has joined #aarch64-laptops
Libre___ has joined #aarch64-laptops
kalebris has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
akaWolf has joined #aarch64-laptops
jbru has quit [resistance.oftc.net charon.oftc.net]
martiert has quit [resistance.oftc.net charon.oftc.net]
bluerise has quit [resistance.oftc.net charon.oftc.net]
kalebris has quit [resistance.oftc.net charon.oftc.net]
tobhe_ has quit [resistance.oftc.net charon.oftc.net]
Kelsar has quit [resistance.oftc.net charon.oftc.net]
akaWolf has quit [resistance.oftc.net charon.oftc.net]
alpernebbi has quit [resistance.oftc.net charon.oftc.net]
Mary has quit [resistance.oftc.net charon.oftc.net]
xroumegue has quit [resistance.oftc.net charon.oftc.net]
ellyq has quit [resistance.oftc.net charon.oftc.net]
fossdd has quit [resistance.oftc.net charon.oftc.net]
Libre___ has quit [resistance.oftc.net charon.oftc.net]
krei-se has quit [resistance.oftc.net charon.oftc.net]
hightower2 has quit [resistance.oftc.net charon.oftc.net]
ektor5 has quit [resistance.oftc.net charon.oftc.net]
pstef has quit [resistance.oftc.net charon.oftc.net]
kettenis has quit [resistance.oftc.net charon.oftc.net]
suihkulokki has quit [resistance.oftc.net charon.oftc.net]
calebccff has quit [resistance.oftc.net charon.oftc.net]
sera[m] has quit [resistance.oftc.net charon.oftc.net]
f_ has quit [resistance.oftc.net charon.oftc.net]
jhovold has quit [resistance.oftc.net charon.oftc.net]
shoragan has quit [resistance.oftc.net charon.oftc.net]
martiert_work has quit [resistance.oftc.net charon.oftc.net]
agl has quit [resistance.oftc.net charon.oftc.net]
abcdw has quit [resistance.oftc.net charon.oftc.net]
pbsds has quit [resistance.oftc.net charon.oftc.net]
abelvesa has quit [resistance.oftc.net charon.oftc.net]
krzk has quit [resistance.oftc.net charon.oftc.net]
djakov has quit [resistance.oftc.net charon.oftc.net]
alexeymin has quit [resistance.oftc.net charon.oftc.net]
javierm has quit [resistance.oftc.net charon.oftc.net]
flokli has quit [resistance.oftc.net charon.oftc.net]
HdkR has quit [resistance.oftc.net charon.oftc.net]
hexa- has quit [resistance.oftc.net charon.oftc.net]
maz has quit [resistance.oftc.net charon.oftc.net]
agraf has quit [resistance.oftc.net charon.oftc.net]
jelly has quit [resistance.oftc.net charon.oftc.net]
baryluk3 has quit [resistance.oftc.net charon.oftc.net]
exeat has quit [resistance.oftc.net charon.oftc.net]
Esmil has quit [resistance.oftc.net charon.oftc.net]
juergh has quit [resistance.oftc.net charon.oftc.net]
Erisa has quit [resistance.oftc.net charon.oftc.net]
cyrinux has quit [resistance.oftc.net charon.oftc.net]
indy has quit [resistance.oftc.net charon.oftc.net]
JoshuaAshton has quit [resistance.oftc.net charon.oftc.net]
xnox has quit [resistance.oftc.net charon.oftc.net]
kbingham has quit [resistance.oftc.net charon.oftc.net]
minecrell754 has quit [resistance.oftc.net charon.oftc.net]
ema has quit [resistance.oftc.net charon.oftc.net]
akaWolf has joined #aarch64-laptops
jbru has joined #aarch64-laptops
Libre___ has joined #aarch64-laptops
fossdd has joined #aarch64-laptops
Kelsar has joined #aarch64-laptops
martiert has joined #aarch64-laptops
Mary has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
bluerise has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
xroumegue has joined #aarch64-laptops
ellyq has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
kalebris has joined #aarch64-laptops
f_ has joined #aarch64-laptops
sera[m] has joined #aarch64-laptops
ektor5 has joined #aarch64-laptops
jelly has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
martiert_work has joined #aarch64-laptops
kettenis has joined #aarch64-laptops
shoragan has joined #aarch64-laptops
agl has joined #aarch64-laptops
juergh has joined #aarch64-laptops
pbsds has joined #aarch64-laptops
pstef has joined #aarch64-laptops
baryluk3 has joined #aarch64-laptops
flokli has joined #aarch64-laptops
calebccff has joined #aarch64-laptops
Erisa has joined #aarch64-laptops
hexa- has joined #aarch64-laptops
ema has joined #aarch64-laptops
exeat has joined #aarch64-laptops
djakov has joined #aarch64-laptops
indy has joined #aarch64-laptops
abcdw has joined #aarch64-laptops
alexeymin has joined #aarch64-laptops
minecrell754 has joined #aarch64-laptops
HdkR has joined #aarch64-laptops
JoshuaAshton has joined #aarch64-laptops
abelvesa has joined #aarch64-laptops
krzk has joined #aarch64-laptops
suihkulokki has joined #aarch64-laptops
xnox has joined #aarch64-laptops
kbingham has joined #aarch64-laptops
Esmil has joined #aarch64-laptops
javierm has joined #aarch64-laptops
maz has joined #aarch64-laptops
agraf has joined #aarch64-laptops
cyrinux has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
travmurav[m] has joined #aarch64-laptops
<travmurav[m]> robclark: "but the more accureate statement is that qcom soc's don't allow VMs with kvm" <- I'd like to interject for a moment and clarify that it's qcom's firmware decision, not some hardware limitation, and I'd bet that both on the red laptop, and //i'm very hoping// on the devbox where hw secureboot is disabled, one can just flash better hyp firmware and boot in el2. Presumably someone already does that with whatever automotive
<travmurav[m]> thing is derived from 8c3
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<travmurav[m]> (also still that funny button on the red laptop for "el2 with kvm" presumably exists so who knows)
maz has quit [Server closed connection]
maz has joined #aarch64-laptops
JensGlathe[m] has joined #aarch64-laptops
<JensGlathe[m]> That email from QCom came to "Get my Devkit now" - looks like a decoy for now. Not in stock, minimum quantity 80 🤨 Only @ Arrow
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
systwi has joined #aarch64-laptops
javierm has quit [Server closed connection]
javierm has joined #aarch64-laptops
agraf has quit [Server closed connection]
agraf has joined #aarch64-laptops
pstef has quit [Read error: Connection reset by peer]
pstef has joined #aarch64-laptops
<mani_s> bluerise, regarding 'Did anyone try ITS MSIs?' On which platforms you were asking for?
LucasTreffenstdt[m] has joined #aarch64-laptops
<LucasTreffenstdt[m]> Good morning. I recently bought a T14s using the x1e soc and I'm interested in running Linux on it.
<LucasTreffenstdt[m]> - since I couldn't find any info on the GitHub, is there something like a "getting started" I could read?
<LucasTreffenstdt[m]> - is there anything I can do to help the development effort? I am a software developer, but I don't have any experience with kernel work or the like
srinik has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
krzk has quit [Server closed connection]
krzk has joined #aarch64-laptops
abelvesa has quit [Server closed connection]
abelvesa has joined #aarch64-laptops
JosDehaes[m] has joined #aarch64-laptops
<JosDehaes[m]> Hello, I got my yoga slim 7x, and was able to install debian using the debian 12 installer that Abel posted on gitlab. However, how can I get into EFI shell?
<JosDehaes[m]> using shellaa64.efi?
<bluerise> mani_s: on x1e; I saw an x1e diff on lkml so I'm assuming for Linux kernel it works and there's something in our OpenBSD kernel that is wrong with the GICv4
<mani_s> bluerise, yep, on linux ITS works with the provided EventIDs
HdkR has quit [Server closed connection]
<bluerise> yeah, I saw the dts diff and I think I'm using the same, because also ACPI mode correctly translates to these
HdkR has joined #aarch64-laptops
<bluerise> OpenBSD runs with either ACPI or DTS on the x13s and x1e; we implemented bare support for the necessary QC ACPI devices to do an install and then provide a DTS through a firmware package
<bluerise> hence why I'm not blaming my DTS but something else in our drivers
<HdkR> JensGlathe[m]: I managed to yoink a devkit on Arrow. Took an hour of refreshign for their server to stop getting angry
Jasper[m] has joined #aarch64-laptops
<Jasper[m]> HdkR: Ohh nice
srinik has quit [Remote host closed the connection]
<HdkR> Maybe actually sold out now
srinik has joined #aarch64-laptops
<Jasper[m]> HdkR: How was shipping?
<HdkR> I got next day so expensive AF
<Jasper[m]> Kind of annoying for me that it ships from the US, means the 899$ pricepoint will stumble over 1k€ for me :/
<Jasper[m]> s/for me//
<HdkR> ah, I'm in the US so hard to judge shipping out of the country :)
<jhovold> Here's an updated wip branch for the X13s:
<jhovold> Changes include:
<jhovold> - fix camera failure to start pipeline
<jhovold> - johan_defconfig: enable FW_LOADER_COMPRESS
<jhovold> Known issue:
<jhovold> - thermal zone warnings (regression in 6.10-final)
srinik has quit [Ping timeout: 480 seconds]
alexeymin has quit [Server closed connection]
alexeymin has joined #aarch64-laptops
srinik has joined #aarch64-laptops
<steev> thanks johan
<bluerise> LucasTreffenstdt[m]: just wondering, what kind of BIOS options does the T14s have?
<bluerise> There's nothing about device tree, linux or EL2?
<steev> bluerise: i think we're still waiting for acpi tables from t14s, at least, i don't see it in https://github.com/aarch64-laptops/build/tree/master/misc or pull requests
<LucasTreffenstdt[m]> bluerise: I can check. steev: can I extract those somehow from the device?
<steev> LucasTreffenstdt[m]: indeed you can, in windows even, however at the moment i can't recall the exact command(s) to use, but it does require acpica-tools (i think is the name)
<steev> i thought maybe in one of the commits, the commands were listed, but alas
<Jasper[m]> Be sure to leave put the msdn table since that includes your windows key
srinik has quit [Remote host closed the connection]
<Jasper[m]> *out
<LucasTreffenstdt[m]> bluerise: I can't find any options related to that, but I might not know enough to find them. It seems to be possible to add your own secure boot keys, which should come in handy.
<steev> https://x0rw3ll.com/re/acpi/acpi-analysis.html - acpidump > acpidump and then acpixtract acpidump looks like
<steev> buddy of mine went into a deep dive into acpi on his laptop, heh
<Jasper[m]> I've used SSDTTime before and then with iasl.exe to decompile
<steev> i think i tried ssdttime but that way a long time ago and i failed spectacularly :)
<steev> but, in my defense, i'm dumb
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<LucasTreffenstdt[m]> Okay, I think I got the files... I'll raise a PR
<steev> i *think* someone else here has a t14s too, but i don't recall their name.
srinik has joined #aarch64-laptops
srinik has quit [Remote host closed the connection]
<LucasTreffenstdt[m]> https://github.com/aarch64-laptops/build/pull/104 I think that's the correct files? I mostly went by what I found in the other directories.
<steev> dmitry already merged it :)
<LucasTreffenstdt[m]> Oh hey, someone was really fast 😳
<steev> lumag does a lot of graphics work
<steev> oh he's in here, oops, sorry for the ping
<lumag> n/p
<HdkR> Nice
<HdkR> Will the dev kit's ACPI tables need to be dumped?
srinik has joined #aarch64-laptops
<HdkR> I could probably do that before I annihilate the Windows install
djakov has quit [Remote host closed the connection]
djakov has joined #aarch64-laptops
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
srinik has quit [Read error: Connection reset by peer]
abcdw has quit [Server closed connection]
abcdw has joined #aarch64-laptops
<Jasper[m]> <HdkR> "Will the dev kit's ACPI tables..." <- Always good to have I guess?
<Jasper[m]> wdk2023 is also in there
jluthra has joined #aarch64-laptops
<HdkR> cool
ema has quit [Quit: leaving]
<JensGlathe[m]> Was anybody able to order a SnapDragon Dev Kit?
ema has joined #aarch64-laptops
<HdkR> I ordered one
<HdkR> It was an hour of refreshing the page until it stuck long enough that it was in stock
<JensGlathe[m]> that appears to be over now
<spawacz> How to turn on the keyboard lights in the x13s?
fossdd has quit [Remote host closed the connection]
fossdd has joined #aarch64-laptops
\[m] has joined #aarch64-laptops
<\[m]> ctrl spacebar?
<abby> fn spacebar
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
hexa- has quit [Server closed connection]
hexa- has joined #aarch64-laptops
flokli has quit [Server closed connection]
flokli has joined #aarch64-laptops
<spawacz> Thanks, I will try
pbsds has quit [Server closed connection]
pbsds has joined #aarch64-laptops
nscnt[m] has joined #aarch64-laptops
<nscnt[m]> <HdkR> "It was an hour of refreshing the..." <- The X1E Snapdragon Dev Kit?
<HdkR> nscnt[m]: yes
<nscnt[m]> wut
<nscnt[m]> when where
<nscnt[m]> I've been waiting all the time
<JensGlathe[m]> The site has changed a little
<JensGlathe[m]> so next round by end of July as it seems
<nscnt[m]> Maybe it was a mistake that it was available to order in the first place?
<nscnt[m]> HdkR: Have you received a confirmation?
<HdkR> yea
<HdkR> I'll report when I get a shipping notification
agl has quit [Server closed connection]
agl has joined #aarch64-laptops
martiert_work has quit [Server closed connection]
shoragan has quit [Server closed connection]
jhovold has quit [Server closed connection]
jhovold has joined #aarch64-laptops
martiert_work has joined #aarch64-laptops
<Jasper[m]> <JensGlathe[m]> "so next round by end of July..." <- Aha
f_ has quit [Server closed connection]
f_ has joined #aarch64-laptops
MrCatfood[m] has joined #aarch64-laptops
sera[m] has quit [Server closed connection]
sera[m] has joined #aarch64-laptops
Eighth_Doctor has joined #aarch64-laptops
<Eighth_Doctor> bluerise: hold on, you can boot OpenBSD through ACPI?
<Eighth_Doctor> so then that means that it's entirely a Linux thing that we are forced to use DTs?
<Eighth_Doctor> rather than UEFI+ACPI?
<robclark> Eighth_Doctor: on previous gens you could boot with basic functionality (nothing accelerated, no cpufreq, etc) with ACPI.. I guess that would be doable on x1e as well. But anything beyond basic functionality you need dt
<Eighth_Doctor> so how does windows avoid this?
<robclark> basically a driver that implements all the acpi power state control for the system
<robclark> linux has no such thing.. and it might not really fit all that well with how things are wired up in a dt based world
<robclark> it would be nice if we could keep acpi for board level stuff but dt for SoC level stuff.. that would solve a lot of problems.. but tbh initial dts support for a couple laptops came within days of people receiving hw so dt isn't _that_ big of a problem. (All the SoC level x1e80100.dtsi bits were already in place.)
<bluerise> Eighth_Doctor: I can boot with ACPI for basic use (framebuffer, NVMe, keyboard/touchpad, USB)
<bluerise> but the ACPI tables are completely shit
<Eighth_Doctor> but I don't want a DT based world :/
<bluerise> everything apart from that, you don't want to touch
<Eighth_Doctor> ugh
<Eighth_Doctor> well okay if the ACPI tables are garbage
<bluerise> Well with x86 ACPI might have been reasonably designed
<Eighth_Doctor> x86 ACPI was designed with the lessons of all the crap before it
<Eighth_Doctor> APM and the litany of weird stuff before that
freekurt[m] has joined #aarch64-laptops
<freekurt[m]> I don't plan on running Windows for any reason on my x13s after I install gnu+linux on the SSD. Is there any reason why I should still create a windows recovery drive or anything else I should do in Windows before I nuke it? I am running 6.10 rc7 and didn't seem to need my wifi or bluetooth mac addresses, both just worked.
<bluerise> Somewhere I heard that Windows didn't support as many function definitions or whatever, that's one of the reasons they do this ACPI thing
<Eighth_Doctor> it would really not surprise me if ARM ACPI was designed without any thought about how badly things were before it
<bluerise> Eighth_Doctor: just to give a bit of insight: the windows drivers attach to the bare ACPI nodes, and the drivers provide a) an ACPI overlay b) an ACPI table parser -- and then they use those
<bluerise> That's basically admitting that the ACPI tables are garbage, if you ship fresh overlays/tables in each driver
<abby> freekurt[m]: you don't need the bt/wlan macs, they just get set to a random one on boot (unless your distro has something to set it to a stable address)
<robclark> I think ACPI is good enough for arm server stuff, because power management there is simpler.. but the thought of implementing clock controllers, icc, etc in AML is a bit terrifying. Which is probably why they came up with this PEP back-door
<Eighth_Doctor> bluerise: yeah, that's basically DT by another name
<bluerise> robclark: +2
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
* travmurav[m] doesn't understand why people hate DT
colemickens has joined #aarch64-laptops
<colemickens> adamcstephens: let me know if you want to try. I have a USB image that I've somewhat verified in qemu. I've hacked something together to get systemd-boot-builder.py to output a devicetree line, it's got abelvesa's kernel, and linux-firmware + linux-firmware-x1e (thanks to .sera). It's sitting on the aarch64 community box that I see you have an account on. Maybe just an rsync/dd away from testing.
<colemickens> (Though, I guess I still want to look at what build of mesa I should include too, presumably there's unreleased bits that might be nice to have.)
hightower3 has joined #aarch64-laptops
maz_ has joined #aarch64-laptops
calebccff_ has joined #aarch64-laptops
clover[m] has joined #aarch64-laptops
<clover[m]> steev: the hurricane Beryl knocked me off the matrix for over a week. I am curious if you've released a kernel since 6.9.5
colemickens has quit [reticulum.oftc.net helix.oftc.net]
MrCatfood[m] has quit [reticulum.oftc.net helix.oftc.net]
hightower2 has quit [reticulum.oftc.net helix.oftc.net]
djakov has quit [reticulum.oftc.net helix.oftc.net]
nscnt[m] has quit [reticulum.oftc.net helix.oftc.net]
Jasper[m] has quit [reticulum.oftc.net helix.oftc.net]
agraf has quit [reticulum.oftc.net helix.oftc.net]
maz has quit [reticulum.oftc.net helix.oftc.net]
kettenis has quit [reticulum.oftc.net helix.oftc.net]
suihkulokki has quit [reticulum.oftc.net helix.oftc.net]
ektor5 has quit [reticulum.oftc.net helix.oftc.net]
calebccff has quit [reticulum.oftc.net helix.oftc.net]
ektor5 has joined #aarch64-laptops
agraf has joined #aarch64-laptops
suihkulokki has joined #aarch64-laptops
kettenis has joined #aarch64-laptops
calebccff_ has quit []
colemickens has joined #aarch64-laptops
djakov has joined #aarch64-laptops
nscnt[m] has joined #aarch64-laptops
calebccff has joined #aarch64-laptops
MrCatfood[m] has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
<JosDehaes[m]> does anybody have the X1E80100-LENOVO-Yoga-Slim7x-tplg.bin ?
martiert has quit [Ping timeout: 480 seconds]
<\[m]> <HdkR> "Jens Glathe: I managed to..." <- you ordered 80?
<HdkR> lol, no
<Jasper[m]> <JosDehaes[m]> "does anybody have the X1E80100-..." <- Are the drivers available from lenovo's website?
<Jasper[m]> In general
<JensGlathe[m]> I just got through the angry phase after registering, switching over to Windows and Edge, and selecting the right payment method. What a CF of a commercial site. But... I got an order confirmation, and the credit card said "paid"
<Jasper[m]> <travmurav[m]> "doesn't understand why people..." <- Chicken and egg, plus the fact that Linux has somehow coped with ACPI on x86 and people don't understand how it works on qcom platforms
<Jasper[m]> JensGlathe[m]: On Arrow?
<JensGlathe[m]> yep
<Jasper[m]> JensGlathe[m]: You were able to order a device?
<JensGlathe[m]> 80 😏
<Jasper[m]> JensGlathe[m]: Yo drop one in my postal box please
<Jasper[m]> thanks
<JensGlathe[m]> you can only order one per customer now. This shows when you're logged in
<Jasper[m]> button still says quote for me sadly
<Jasper[m]> JensGlathe[m]: oh
<Jasper[m]> OH
<Jasper[m]> yeah let me do that real quick
<Jasper[m]> How's the shipping, you live closer to me than @HdkR
<JensGlathe[m]> no idea, no mark up listed for shipping (it said free), but something something tariffs. I expect to pay something when bailing the package out of the DHL store
<Jasper[m]> Yeah tariffs are somewhat of a given
<Jasper[m]> kinda sad they don't list those then, customs handling by DHL is absolute shit here
<JensGlathe[m]> and VAT on import I would assume, another 160€. In that range
<JensGlathe[m]> so it will round up to ~1000€, give or take
<HdkR> Jasper[m]: $120-ish for next-day
<Jasper[m]> Ah yes, need to be a company to register boooooooo
<HdkR> Oh, different question. Read the full convo now :D
<Jasper[m]> HdkR: no worries hahaha
<JensGlathe[m]> Oldschool Solutions has spend its R&D budget on this box
<Jasper[m]> Ah wait, I may have messed up
<Jasper[m]> I thought the myarrow account was the one you needed to register for hahahahaha
<Jasper[m]> Wait is it? I thought it said something about "registering for access to their global inventory"
<JensGlathe[m]> I have ordered as private and with company name and VAT ID. Avoided the odd myarrow button. Nothing works as intended in this site.
<Jasper[m]> Ah crap, let me see where I can register that then
<Jasper[m]> I found the right register page too, but I think it says my email is in use due to the request to use myarrow
<Jasper[m]> that's such bad ux
<JensGlathe[m]> top level ux
<Jasper[m]> I did do the cheeky mail subscription thing, that should soften the blow a bit pricingwise
<JensGlathe[m]> forget it. Nothing happens
<Jasper[m]> I mean they now also didn't set my password
<JensGlathe[m]> But since we actually want the kit... we put up with it
<JensGlathe[m]> the password save dialogue doesn't work as intended, hat to edit it afterwards
<HdkR> I noticed arrow has a fun case-sensitive account name problem as well. If you don't throw all lowercase at them, then they force a password reset
<Jasper[m]> JensGlathe[m]: I.. can't login
<HdkR> It's an amazingly buggy interface
<JensGlathe[m]> Windows, Edge? Didn't work on ff anywhere. At least when you wanted to pay eventually
<Jasper[m]> AM I BEING RATELIMITED????
<JensGlathe[m]> we are
<Jasper[m]> HAHAHAHAHHA
<JensGlathe[m]> The whole torture takes a while, as HdkR already pointed out
<HdkR> I also used two browsers and deleting local site storage to force a refresh
<travmurav[m]> <Jasper[m]> "Chicken and egg, plus the fact..." <- meh easy to use anything if everything is either on spec-fxied mmio or a discoverable bus
<HdkR> Arrow's web front is nearly as busted as when NVIDIA used Digital River for sales :D
<travmurav[m]> I bet no one would complain if linux were to just silently load a compiled-in dtb based on the dmi and just pretend acpi is used
maz_ is now known as maz
<JensGlathe[m]> are those adsp and cdsp dtbs encrypted?
<robclark> probably just signed
<robclark> they are packed as an elf file somehow.. haven't tried to extract the dtb bit
<travmurav[m]> iirc qcom likes to reuse their elf signing thing for everything so I guess the fdt is just in some data segment of the elf? could probably just binwalk it then ig
<travmurav[m]> but I guess those dtbs would just have some per-board config kvs for the *dsp firmware anyway
<Jasper[m]> <travmurav[m]> "I bet no one would complain if..." <- I mean that solves the chicken and egg problem
<JensGlathe[m]> could be useful information perhaps
<Jasper[m]> Finally logged in
<Jasper[m]> Chrome works better indeed
<Jasper[m]> "ships tomorrow" interesting
<Jasper[m]> Wish I could see the checkout button though, or is that too much to ask? :^)
<JensGlathe[m]> I had to reload the checkout page. Reachable via shopping basket
<Jasper[m]> I... do not have a VAT id
<JensGlathe[m]> oh is it equired?
<JensGlathe[m]> * oh is it required?
<Jasper[m]> Yes, on arrow.com
<JensGlathe[m]> ordered as private?
<Jasper[m]> JensGlathe[m]: How
<JensGlathe[m]> Shipping address I guess
<JensGlathe[m]> it was in the top part of the form
<Jasper[m]> Do you mean when registering or at checkout?
<JensGlathe[m]> at checkout, ship to
<Jasper[m]> Yeah I did
<Jasper[m]> dammit
<\[m]> I just ordered one too, somewhat painlessly
<\[m]> the vat ID was optional
<Jasper[m]> I must've done something wrong
<\[m]> it also said something duty paid - I thought that was import costs but I'm really bad at such things so am probably misunderstanding and will get slapped with import costs huh
<Jasper[m]> Or this is ANOTHER issue with the UX (on mobile?)
<\[m]> Jasper[m]: I'm pretty tired so maybe I lucked out clicking "wrong" 😄
<\[m]> am on laptop yeah
<\[m]> I changed to euro then entered 1 and clicked quote but it gave a pop up to add to cart 🙂
<JensGlathe[m]> I had to explicitly fail (refresh cart) and close all parallel sessions on all devices before I could order, prop IP address check
<JensGlathe[m]> s/prop/prob/
<JensGlathe[m]> this ux is really, really top notch annoyance
<Jasper[m]> "You must verify a VAT-ID"
<Jasper[m]> Am I just not supposed to register or smth?
<\[m]> > next-gen AI application development for Windows on Snapdragon
<\[m]> lol I"m going to weld a screen on and glue a keyboard and apple trackpad hahaha diy cheapo development
<\[m]> Jasper[m]: I had too - you can buy on my company if you want
<\[m]> I will gladly book that invoice 🙂
<JensGlathe[m]> if you're in the same country this should work
<Jasper[m]> JensGlathe[m]: We're not I think
<\[m]> afaik, only thing that matters is that my vat number is on the invoice
<\[m]> you order on the company, delivery address something else
<JensGlathe[m]> I had to leave out the country indicator of the VAT ID ("DE") on my attempts. From what I know re backend, it should better be a VAT matching the country (usually also address) to go through the SANSCREEN check
<JensGlathe[m]> I would recommend to try from a indows box
<JensGlathe[m]> s/indows/Windows/
<JensGlathe[m]> even if it scorches the skin
<maz> I added Arrows's own VAT ID... went though...
<Jasper[m]> maz: What the fuck hahahahah
<maz> with a bit of luck, they also get to pay for the import taxes! :D
<Jasper[m]> I should ask at work if I can order it off their thing
<Jasper[m]> No idea how they deal with that though, only one way to find out
<JensGlathe[m]> if you're an asset no prob
FarchordSteveCossette[m] has joined #aarch64-laptops
<JensGlathe[m]> Some distributors should order at least 80 to make them available
<FarchordSteveCossette[m]> I hate myself.
<JensGlathe[m]> Nice. You'll get over it
<JensGlathe[m]> Was tempted after the DevKit fiasco to order a T14s, but was rescued (yet).
<FarchordSteveCossette[m]> JensGlathe[m]: The T14s is so dang expensive here
<FarchordSteveCossette[m]> It would've cost me almost double for worse specs
<\[m]> <JensGlathe[m]> "if you're an asset no prob" <- who ever is though
<JensGlathe[m]> hmm I guess I will end up with one anyway, eventually.
<JensGlathe[m]> \[m]: Everybody thnks he is
<\[m]> <FarchordSteveCossette[m]> "I hate myself." <- future you loves you 😄
<JensGlathe[m]> s/thnks/thinks/
<\[m]> FarchordSteveCossette[m]: but those pg up pg down buttons though 💦
<FarchordSteveCossette[m]> \[m]: And yet, present me's brain is currently giving myself an atomic wedgie
<JensGlathe[m]> I just need an excuse, but even "It's my hobby" carries only so far
<FarchordSteveCossette[m]> JensGlathe[m]: I went with the childish approach: "Because I waaaanaaaaaa"
<FarchordSteveCossette[m]> And I don't have a significant other
<\[m]> these have oled right ? that's a good price I think - what's the cpu?
<JensGlathe[m]> FarchordSteveCossette[m]: That's okay. You've invested into the AI future ™️
<FarchordSteveCossette[m]> Snapdragon® X Elite X1E 78 100 Processor 3.4GHz (42MB Cache, up to 3.4GHz, 12 cores, 12 Threads); Qualcomm® AI Engine up to 75 total TOPs
<\[m]> JensGlathe[m]: if you don't go out more than 20 times a year, it's granted 😄
<JensGlathe[m]> \[m]: I have more than one hobby. And an accountant as wife
<\[m]> just wait when you can't manage to make it usable for a year hahaha
<\[m]> FarchordSteveCossette[m]: seems like all SKUs are pushing this 78 one or what
<JensGlathe[m]> \[m]: The exerience of the last year with the wdk2023 makes me bold enough
<\[m]> except for the devkit mm
<FarchordSteveCossette[m]> \[m]: For asus, yes
<JensGlathe[m]> the devkit has the biggest chip
<\[m]> oh yeah the vivobook, I would buy it if not for that numpad
<\[m]> like why
<FarchordSteveCossette[m]> \[m]: I love the numpad
<FarchordSteveCossette[m]> See that CPU is the lowest in the elite series, but....
<FarchordSteveCossette[m]> seems like Asus uses a different power profile
<FarchordSteveCossette[m]> ....maybe?
<\[m]> I don't think I need a bigger cpu but want? mm
<\[m]> in the end it just eats more power right
<Eighth_Doctor> <JensGlathe[m]> "Was tempted after the DevKit..." <- the fact that I don't really have the money to spend is the only reason I haven't pulled the trigger on anything yet
<JensGlathe[m]> tempted despite this.
<Eighth_Doctor> it doesn't help that the T14s is expensive and doesn't really have the kind of quality screen I expect at the price point it is
<Eighth_Doctor> the vivobook would have been tempting if I didn't hate numpads on laptop keyboards so much
<Eighth_Doctor> the vivobook is $200 more than the devkit
<Eighth_Doctor> so it would be worth it at that point
<FarchordSteveCossette[m]> To me, the numpad is it's selling point
<FarchordSteveCossette[m]> and it'S a 16" laptop (Well, okay, 15.6")
<FarchordSteveCossette[m]> As soon as I get it I'm prolly gonna try to image the main drive. I have a 2tb nvme drive I wanna use here
iivanov has quit [Quit: Leaving...]
<Jasper[m]> Well crap, I'm not going to find anyone with a VAT id lmao
<steev> clover[m]: indeed i have
echanude has quit [Ping timeout: 480 seconds]
hightower3 has quit [Remote host closed the connection]
hightower3 has joined #aarch64-laptops
<robclark> bamse, abelvesa, or anyone who happens to have an x1e crd... could you upload acpi tables? It would help to be able to compare laptop acpi dumps to crd, to figure out what is in common
jhovold has quit [Ping timeout: 480 seconds]
<steev> clover[m]: glad things are okay now for you though, luckily beryl went wide right of us. that said, i've got 6.10 out which is based on johan's 6.10 and adds my bits, as well as some misc fixes that are coming
echanude has joined #aarch64-laptops
<Eighth_Doctor> <FarchordSteveCossette[m]> "As soon as I get it I'm prolly..." <- I expect that it won't work right away without some custom images being made, since you need non-upstream fixes in linux and uboot
<FarchordSteveCossette[m]> Eighth_Doctor: It'll work in time.
<Eighth_Doctor> yes, for sure