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
<freekurt[m]>
I wish I could close the lid to my x13s or turn off its monitor when using my external monitor. It doesn't look like I can do either though. Does anyone happen to know why this is?
<travmurav[m]>
I thought the hall sensor on x13s is just wired to a gpio
<travmurav[m]>
So it should work, but I guess you could test that evtest logs lid events
<travmurav[m]>
Otherwise I guess it'd be software, gnome handles lid very nicely for me on another thing (I.e. auto disables the internal display)
<jhovold>
freekurt[m]: there's a systemd config setting for that
<jhovold>
logind.conf / HandleLidSwitch= ...
srinik has joined #aarch64-laptops
davidk has quit [Remote host closed the connection]
srinik has quit [Ping timeout: 480 seconds]
pbrobinson has quit [Ping timeout: 480 seconds]
pbrobinson has joined #aarch64-laptops
davidk has joined #aarch64-laptops
hswanh has joined #aarch64-laptops
<hswanh>
Hi
hswanh has quit [Remote host closed the connection]
sally has joined #aarch64-laptops
davidk has quit [Read error: Connection reset by peer]
davidk has joined #aarch64-laptops
davidk has quit [Remote host closed the connection]
<JensGlathe[m]>
How polite a critique can you write? "...did not materialize" oof
pbrobinson has quit [Ping timeout: 480 seconds]
<Jasper[m]>
Sadly no mention of PEP at the end there
<Jasper[m]>
Also I think it's important to mention that there's a distinct lack of vendor support aswell. Maybe excluding Tuxedo and Lenovo then.
<JensGlathe[m]>
yeah, which would put the blame somewhere
<Jasper[m]>
It is a big part of the issue. Even if qualcomm had upstreamed a driver for every subsystem and hardware combo made by them (which they haven't, neither for sc8280xp), there's still no DT for actual devices to boot off, nor will device specific features that may not have a driver, be supported.
kalebris has quit [Remote host closed the connection]
kalebris has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
ravikant_ has joined #aarch64-laptops
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
ravikant_ has quit [Ping timeout: 480 seconds]
<anthony25>
and the fact that the power consumption not being that low yet (compared to windows), means that compared to a modern x86 laptop, it's difficult to convince other than for the fun aspect
<anthony25>
so it's way more trade-offs than actual benefits for the moment
AldairsilvaSilva[m] has joined #aarch64-laptops
pbrobinson has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
SpieringsAE has quit []
ravikant_ has joined #aarch64-laptops
ravikant_ has quit []
jhovold has quit [Quit: WeeChat 4.4.3]
<robclark>
JosDehaes[m]: "The ARM desktop/laptop revolution seems mostly confined to Apple for now." ... that is a pretty unfair statement, considering the state of upstream support for apple devices.
<robclark>
(to put it mildly)
<travmurav[m]>
on the other hand if you just consider aa64 laptops regardless of the OS, apple is probably first
<JensGlathe[m]>
yea
<JensGlathe[m]>
That secrecy fetish they all have, though
<robclark>
sure, but they've had a bit of a head start, and a lot more control over their ecosystem
reng has quit [Remote host closed the connection]
reng has joined #aarch64-laptops
luca020400 has quit [Quit: WeeChat 4.5.0]
luca02041 has joined #aarch64-laptops
luca02041 is now known as luca020400
srinik has quit [Ping timeout: 480 seconds]
<Eighth_Doctor>
<robclark> "Jos Dehaes: "The ARM desktop/..." <- honestly, I don't know if I completely disagree
<Eighth_Doctor>
WoA devices aren't doing well
<Eighth_Doctor>
and there are no commercially viable good Linux ARM laptops either
<Eighth_Doctor>
And as the bringup model currently stands for ARM laptops, it's not going to scale well, since the DeviceTree problem fundamentally limits how well Linux can support these things
<Eighth_Doctor>
the worst case scenario is that a glut of WoA devices ship and all of them have effectively non-functional ACPI
<JensGlathe[m]>
well thats the case now
<robclark>
apple laptops running linux are using devicetree as well.. (not that I disagree that it is a scaling problem in the current state of things where the community is providing dtb... it is totally _not_ a scaling problem for chromebooks)
<Eighth_Doctor>
yes I know
<Eighth_Doctor>
it's the part that sucks the most about the bringup since we (asahi) need to own every mac :(
<robclark>
also, not sure that WoA is doing badly, apparently as of Jan x1 was 10% of the market in the segments that they had a presence, which is not bad at this stage..
<jannau>
that has very little to do with devicetree or acpi
<travmurav[m]>
"need to own every mac" <- same for woa isn't it - the /community/ has to own every woa to support them all
<travmurav[m]>
but well
<jannau>
the porblem is more that there is zero documentation and has so few models that they can allow to handle everyone individually
<JensGlathe[m]>
travmurav[m]: truth
svarbanov_ has quit [Read error: Connection reset by peer]
<Eighth_Doctor>
<travmurav[m]> ""need to own every mac" <- same..." <- yes, the complexity is just worse because of the higher amount of variation
<travmurav[m]>
yes, with apple more people can focus on fewer devices
<Eighth_Doctor>
it's the same reason that LineageOS mostly focuses on Samsung and Pixel devices
<Eighth_Doctor>
it's impossible to cover everything because we can't do dynamic discovery and configuration
<travmurav[m]>
+ I guess on the board level it's easier to get (leaked) schematics due to them being more often repaired since volume is bigger (otoh need to RE everything platform wise compared to qc that does some upstreaming themselves)
<Eighth_Doctor>
no Plug-and-Play functionality for ARM platforms
<Eighth_Doctor>
I wish Arm actually cared about this the same way Intel did in the 90s
<Eighth_Doctor>
but unfortunately, they believe that it's not their place to drive standardization of ARM platforms
<travmurav[m]>
easy to force on a standard if you are the monopoly
<travmurav[m]>
there is stuff like arm systemready but oh well
<robclark>
arm _servers_ are plug and play, arm has invested a lot in the standardization there. The problem, at least with WoA laptops, is that ACPI is more or less insufficient and linux does not support PEP.. please stop blaming the wrong people/companies
<travmurav[m]>
well one could argue that qc could put everything behind pcie glue and then IP blocks would be "discoverable"
<travmurav[m]>
and they could put the clocks into tz etc etc
<travmurav[m]>
and at some point you get it to x86 level I guess where firmware does a lot of stuff and you get fixed regulators on the board you can't turn off and save some extra milliwats of power in suspend
<robclark>
I suppose with their hyp they could have virtualized it more, but that wouldn't be a great outcome either
<travmurav[m]>
my point is, servers are easy to make work because the soc is just a hunk of pcie and a stray uart
<robclark>
sure, and power mgmt isn't as complex
<travmurav[m]>
a heavily integrated platform like qc where there is like 10+ muliti-core CPUs that need to talk and save power...
<Eighth_Doctor>
and my point is that it's pretty much everyone's fault in the ecosystem that only servers have nice things
<robclark>
travmurav[m]: right, it's a much more complex problem
<Eighth_Doctor>
but Arm as the owner of the platform has most of the blame, in my book
* travmurav[m]
wonders who to blame if same thing happens to a risc-v system
<Eighth_Doctor>
good question
<travmurav[m]>
we can all wish things could be better but the history is already written
<Eighth_Doctor>
riscv is much weirder
<travmurav[m]>
and what we have is woa being made on the foundation of a very thiccc smartphone platform
<Eighth_Doctor>
though I've seen more systems with UEFI+ACPI in riscv space, so there seems to be hope there
<travmurav[m]>
with all the smartphone platform benefits (tight power management) and drawbacks (firmware/control mess)
<Eighth_Doctor>
I keep being promised things will be better, but so far, bupkis
<robclark>
anyways, one possible future is linux just bites the bullet and figures out how to do a PEP equivalent thing
<travmurav[m]>
>hoping things get better
<travmurav[m]>
sorry
<travmurav[m]>
hooray boardfiles
<Eighth_Doctor>
robclark: does that actually fix anything for us?
<robclark>
yeah, idk how much the PEP is customized per laptop... maybe we end up with a glue PEP thing that uses the existing icc/gdsc/cc stuff plus a mini dtb for board customizations, and the vast majority of everything else looks like normal ACPI
<Eighth_Doctor>
from what I gathered, PEPs for Windows are basically DT-like blob things
<Eighth_Doctor>
and still specific to the computer
<travmurav[m]>
pep is a huge huge driver that has everything platform specific inside afaiu
<travmurav[m]>
it's unclear if it's soc-specific or customized per board
<robclark>
they might contain dt for customizations, but they are mostly all the power related drivers (icc/gdsc/cc/etc)
<robclark>
right
<Eighth_Doctor>
I have a gut feeling it's the latter
<robclark>
someone should collect samples of the PEP drivers and disassemble them I guess
<robclark>
anyways, that would still let us re-use everything else that is in acpi
<travmurav[m]>
actually
<travmurav[m]>
I guess new MS installer should include pep for x1e
<travmurav[m]>
iirc they promised generic installer should work
<travmurav[m]>
could infer that pep might be platform-specific and not board then
<robclark>
yeah.. so do they include N different PEPs or ???
<robclark>
right
<robclark>
if it is just platform specific, that isn't really all that bad
<travmurav[m]>
but still my impression that qc/quic doesnt' want to touch pep as of now, and who else but sponsored people would touch that xD