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
<steev>
that is the 6.9 branch, yeah
<steev>
akaWolf: if you watch johan's presentation, pretty much mainline can be used, you just need all the userland bits in place; his branch, and mine, have WIP stuff. i like to test patches, and i push it out so more people can test if they want, but you do not at all need to use either his nor my kernel anymore
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
possiblemeatball has quit [Quit: Quit]
<Dantheman825[m]>
<steev> " - srini's dp audio work (..." <- do I just update my linux-firmware and alsa-ucm-conf packages, or do I have to find an downstream one?
<steev>
debian also has good support, as long as you follow the wiki for the few extra commands that you need to run (and i had no idea you could do some of the things that ema pointed out in it)
<steev>
bumble[m]: end up like the pinephone in what way? at this point, as johan points out, a lot of the issues are very generic and qualcomm side of things, unfortunately
<craftyguy>
yeah this platform and its upstream kernel support is nothing like the pinephone, I'm not sure what they mean by that comment
<akaWolf>
steev: how is audio working for you?
<steev>
fine?
alfredo has joined #aarch64-laptops
jglathe_volterra has joined #aarch64-laptops
alfredo has quit []
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<travmurav[m]>
robclark: I wonder if we can put of_device_is_available() into zap_shader_load_mdt() and set status=disabled for zap shader in the overlay so we don't need to delete the node
<travmurav[m]>
this way booting in el2 on sc8280xp would be fully reduced to applying overlays
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
juergh_ has joined #aarch64-laptops
juergh has quit [Read error: Connection reset by peer]
possiblemeatball has joined #aarch64-laptops
<\[m]>
<bumble[m]> "hope x13s does not end up like..." <- what's wrong with pinephone?
jhovold has joined #aarch64-laptops
<Jasper[m]>
<\[m]> "what's wrong with pinephone?" <- A fairly big amount of unupstreamable fixes
alfredo has quit [Quit: alfredo]
<jhovold>
bumble[m]: thanks, glad you liked it
<bumble[m]>
<\[m]> "what's wrong with pinephone?" <- https://blog.mobian.org/posts/2023/09/30/paperweight-dilemma/ it seems pinephone will never be fully supported with mainline vanilla kernel and activity and interest around pinephone reduced when pinephone pro was released. I'm only a spectator/lurker so please excuse problems with my observation
<jhovold>
akaWolf: audio is working fine with pulseaudio, there are some issues with pipewire still (generic problem with qualcomm audio hw)
<jhovold>
and I did mention that the speaker volume is limited for now in the presentation
<bumble[m]>
also, may be conflating arch-alarm issues I encountered with "linux on pinephone issues" unfairly
<lollaritits[m]>
bumble[m]: linux laptops are definitely more known and usefull than phones
<lollaritits[m]>
i dont think its going to have the same problem
<lollaritits[m]>
i alone have 2 linux laptops with me
<lollaritits[m]>
only 1 on arm
<pstef_>
just a data point, maybe I'm weird but I find the volume to be perfectly within the range of what I expect from a laptop
<Jasper[m]>
pstef_: And that's absolutely respectable
<Jasper[m]>
But in this case you are in the minority (probably)
<Segfault[m]>
yeah it's fairly quiet, definitely quieter than in windows
<Segfault[m]>
<lollaritits[m]> "i alone have 2 linux laptops..." <- i think i've got like 5 within arms reach lmao
<\[m]>
<jhovold> "and I did mention that the..." <- is the audio limitation then under the qualcomm umbrella?
<\[m]>
it's in the fw, this audio limiting thing
<\[m]>
like protection
<\[m]>
<bumble[m]> "also, may be conflating arch-..." <- afaict they standardised on manjaro and that gave a set of results following out of it, some devs dropping off and bad publicity etc
<jhovold>
\[m]: the speaker protection issue is a generic qualcomm issue, yes
<\[m]>
I've never gotten a second sim card to test and the applications are too limited, so if you just want to use basic cell phone features, it's fine but I believe phones are humans swiss army knifes in society now so it was never going to be enough
<jhovold>
the hardware (dsp firmware) supports active speaker protection which would you to push the speakers further without damaging them
<\[m]>
ok I wil listen today jhovold, thanks for all the work !!
<jhovold>
but until we know how to, and get access to the fw required to do so, I
<jhovold>
...I've added a limitation in the sound driver in the kernel to prevent people from killing their speakers
<\[m]>
so did arm reach out to linaro for the projects and then hired you?
<\[m]>
s/projects/project/
<jhovold>
something like that, yeah
<\[m]>
why I'm asking is because I am interested to know if ARM has linux workstations on their radar
<\[m]>
I guess it's not a high priority, jsut piggybacking minimally on woa?
<jhovold>
I don't know, but of course arm's intersted in companies making products using their designs and having people using them
<jhovold>
hopefully we'll see aarch64 laptops sold with Linux preinstalled at some point
<jhovold>
if anything, this project has proven that it is possible, now someone just has to convince the business people...
<Jasper[m]>
I think most of the trouble is having the oem spend time on a DT
<Jasper[m]>
(and including them in a sane manner)
<Jasper[m]>
SLBOUNCE MENTIONED @travmurav
<jhovold>
DT is just a small part here, I'd say
<jhovold>
Qualcomm needs to make sure they have their stuff upstream
<\[m]>
it's not about finding the people that can implement it too?
<\[m]>
I was thinking why QC is lagging behind, it can be many factors
<\[m]>
having the people that have the skills can be one, and having them free to work on maybe lower prio stuff
<jhovold>
that too, and teaaching their engineers about upstream
<Jasper[m]>
jhovold: I agree. I just yearn for SBBR/SBSA's requirement that bootchains are standardised 😢
<Jasper[m]>
Since nothing is included in firmware by default, having an iso just boot is a pipedream
<travmurav[m]>
going full "server ready" is probably not even that needed if oem (or better base qcom firmware) can handle dtbs properly, then sr-IR is probably enough IMO
<travmurav[m]>
and Ive heard qcom people were looking into dtb handling lately
<Jasper[m]>
Oh yeah sure. EBBR was created to be a slightly looser requirement set, but that still leaves too much room for weird and wacky stuff iirc
<travmurav[m]>
well what do we actually care about? having uefi and having the dtb in the system table :P
jhovold has quit [Quit: WeeChat 4.2.2]
<travmurav[m]>
with an alternative being lots of boardfiles for acpi PEP I guess but no one would sponsor /that/ work I'd assume :D
<Jasper[m]>
Oh yeah definitely
<Jasper[m]>
I'm just saying that having some hw work ootb (due to standardization) would be great
<travmurav[m]>
I'm still confused why lenovo didn't opt into shipping a fallback dtb in the firmware, I think when dtbloader was included there already was some basic support upstream so keeping it out seems too cautious
<travmurav[m]>
and afaik as long as upstream bindings are used, dtb is forward and usually backwards compatible
possiblemeatball has quit [Remote host closed the connection]
possiblemeatball has joined #aarch64-laptops
<Jasper[m]>
@jhovold finished the talk, thanks for the work so far!
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
f_ has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
KREYREN_oftc has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
<robclark>
travmurav[m]: overlays can't delete nodes? I thought there was a `/delete-node/` thing
possiblemeatball has quit [Quit: Quit]
<travmurav[m]>
robclark: no, this is a compiler directive but overlay format has no way to specify deletions
<travmurav[m]>
so compile time we can nuke nodes but not "at runtime"
<travmurav[m]>
(and afaik last time someone proposed deletions into the overlay spec, it was many years ago and it was refused)
<robclark>
hmm, sad
<robclark>
yeah, I think maybe the of_device_is_available() approach would work
<ardb>
robclark: +1
<ardb>
i'd argue that it is an oversight that status=disabled does not work today
alfredo has joined #aarch64-laptops
valida-69[m] has quit []
<steev>
welp, that was a fucking waste of 3 days
<steev>
trying to track down this stupid performance regression, and turns out, it's just xz is slow af
<steev>
bumble[m]: re: the mobian post... while i sympathize... the reality is, someone has to pick up the flag. while i know how to apply patches (and holy crap is b4 amazing) - i didn't know all that much about kernel work properly (aside from many grumbles a long time ago when shawngou used to nack all our patches at genesi for the smartbook and smarttop. i'm not "classically trained" as it were (1 semester of college before i dropped
<steev>
out) - i just picked up stuff as i needed it, at some point people have to decide what is important enough to them to put the time into
<pstef_>
b4?
jjardon[m] has quit [Quit: Client limit exceeded: 20000]
juergh1 has quit [Quit: Client limit exceeded: 20000]
<pine-clover[m]>
dang, i was going to work on linux 6.9 for arch peeps but then the freaking storm came through. we've been without power so no homeserver either
nekogirl[m] has quit [Quit: Client limit exceeded: 20000]
<steev>
oh no :(
<pine-clover[m]>
we have a generator so i have my coffee machine, and a small fan going. its not too hot today but temps are supposed to rise tonight and tomorrow i think
cmeerw[m] has quit []
<steev>
at least you have coffee!
<pine-clover[m]>
and a 5G enabled arm-based laptop ;)
underpantsgnome[m] has quit []
jglathe_ has quit [Remote host closed the connection]
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops
bluerise has joined #aarch64-laptops
jglathe_sdbox2 has joined #aarch64-laptops
jglathe_ has joined #aarch64-laptops
jglathe_sdbox2 has quit [Read error: No route to host]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
<akaWolf>
hm does we have glx at x13s?
<HdkR>
akaWolf: GLX works on X13s
<HdkR>
You even get full GL 4.6
<akaWolf>
❯ glxinfo
<akaWolf>
name of display: :0
<akaWolf>
Error: couldn't find RGB GLX visual or fbconfig
<HdkR>
Sounds like a busted driver
<akaWolf>
how to check?
<HdkR>
That would be my personal way to check
<HdkR>
Hopefully your distro didn't do something terrible like disable glx on arm64 builds
<HdkR>
Or fail to enable glvnd
<akaWolf>
HdkR: so share your personal way to check:)
<HdkR>
glxinfo :P
<HdkR>
If glxinfo doesn't work then something is borked
<robclark>
`LIBGL_DEBUG=1 glxinfo` is a good place to start
<akaWolf>
❯ LIBGL_DEBUG=1 glxinfo
<akaWolf>
name of display: :0
<akaWolf>
Error: couldn't find RGB GLX visual or fbconfig
<robclark>
if it gets as far as trying to load mesa, you should see somewhat more than that
<steev>
when mine pops off here, the first thing after the display :0 here is libGLX_mesa and i don't see that in yours. are you exporting LIBGL_ALWAYS_INDIRECT ?
<robclark>
did you install mesa after Xorg started? In that case you'll want to restart X.. otherwise maybe arch has gbm split out into a different package, that you are missing??
<robclark>
if that doesn't work, try to start Xorg from cmdline with LIBGL_DEBUG=1
<akaWolf>
doesn't work
<robclark>
try shutdown UI (`systemctl stop gdm` or something similar), then login on fbcon and `LIBGL_DEBUG=1 LD_DEBUG=libs /usr/libexec/Xorg |& tee /tmp/debug.log`
<akaWolf>
robclark: did you try to run Xorg like this? loooks like startx clears env vars
<robclark>
then switch to a different vt to look at debug.log
<akaWolf>
ok
<robclark>
(or `killall -9 Xorg` if you need to shut it down to start normal desktop session again)
<robclark>
(I'm assuming you don't have a convenient way to ssh to your laptop.. some of this is a bit easier if you can start Xorg from ssh from a different system)
<robclark>
anyways, the point is to figure out why glamor isn't loading, since that is preventing glx from working
<robclark>
MESA-LOADER: failed to open msm: libLLVM-16.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
<robclark>
so in the end we can blame llvm ;-)
<akaWolf>
yeah, thanks
<robclark>
np
<robclark>
I should have just guessed it was llvm.. that would have saved a lot of time :-P
<steev>
replaced 16 with 17 and didn't rebuild mesa smh
<steev>
typical arch
mcbridematt has quit [Read error: Connection reset by peer]
mcbridematt has joined #aarch64-laptops
SintayewGashaw[m] has quit []
DrewCollier[m] has joined #aarch64-laptops
<DrewCollier[m]>
Yoooo
<steev>
sup
<DrewCollier[m]>
Sup are you able to run arch on your arm laptop? I'm running into all kinds of issues just getting it installed.
<steev>
i don't run arch, but there are definitely people here who have and are