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?
<akaWolf> steev: which presentation?
<akaWolf> I still have not loud audio and have problems with quality, doesn't mention in the presentation, so I suppose audio is working fine for you
<akaWolf> it was mentioned a problem with system reset whilst initializing system, which I also have
hightower3 has joined #aarch64-laptops
hightower4 has quit [Ping timeout: 480 seconds]
<adamcstephens> akaWolf: if you're on nixos, I'd humbly suggest https://codeberg.org/adamcstephens/nixos-x13s
<adamcstephens> there's a thread on discourse as well
<akaWolf> adamcstephens: I'm on arch, but I will consider use of nixos, thanks
<akaWolf> just arch linux arm experience isn't too good to be honest, despite my preference of arch linux, I have to state this fact
<adamcstephens> ahh, you were just sharing a nixos link.
<akaWolf> adamcstephens: I've used nixos before
<akaWolf> by the way, there is guix too to give a try with arm
<abby> you'd have to bootstrap from another linux but i've been working on x13s support for void https://github.com/void-linux/void-packages/pull/49615
<craftyguy> pmOS has good support for the x13s, I've been daily driving it since Oct :P
<bumble[m]> hope x13s does not end up like pinephone
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> Dantheman825[m]: no, https://lore.kernel.org/all/20240422134354.89291-1-srinivas.kandagatla@linaro.org/ has the links to the two repos
<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]
<pstef_> phew, for a minute I thought it was a typo
<steev> nah, it's one of the most amazing pieces of software that exists
<steev> it also makes people like me look like we know what we're doing as we stumble around in the dark
arisu has quit []
funderscore has joined #aarch64-laptops
ajhalaney[m] has quit []
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
alfredo has quit [Quit: alfredo]
matrix638[m] has quit []
pine-clover[m] has joined #aarch64-laptops
funderscore is now known as f_
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
<robclark> `LD_DEBUG=libs glxinfo`?
jglathe_volterra has joined #aarch64-laptops
<robclark> idk if it is strange that it is using /usr/lib/ (instead of /usr/lib64 or a multiarch path)
<robclark> I would expect to see it trying to open ${libdri}/dri/${drivername}_dri.so .. but I don't see that..
<HdkR> Could be ALARM which messes that up
<robclark> also not sure if it is weird that it is trying to use libGLX_indirect.so.0 .. but maybe that is a fallback
<robclark> I see it is using libGLdispatch.so.0 .. so glvnd
<robclark> my guess, you have glvnd installed but not mesa??
<akaWolf> robclark: in arch there are no lib64
<akaWolf> all libs are 64 bit
<robclark> no 32b support? I guess that is less relevant on arm than x86, but still
<akaWolf> I guess there is no 32bit support in arch linux arm (not sure)
<akaWolf> robclark: but I have installed mesa
<akaWolf> I have both: mosa and libglvnd
<akaWolf> mesa*
<HdkR> https://github.com/archlinuxarm/PKGBUILDs/blob/master/extra/mesa/PKGBUILD#L158 Looks like it is supposed to provide freedreno and turnip
<jglathe_volterra> glxinfo on Ubuntu 24.04 gives a ton of data https://drive.google.com/file/d/1eP0RlMh0_J5EpuNHJLTbv4WGT07Z-OjJ/view?usp=sharing
<robclark> akaWolf: what is output of `ls /usr/lib/libGL* /usr/lib/dri` ?
<robclark> ok.. looks like probably you are missing some icd files that tell libglvnd to look for libGL*_mesa
<robclark> you have all the right mesa .so's but your LD_DEBUG output doesn't show glvnd lookign for libGL*_mesa .. so I guess it is idc issue
<robclark> hmm, but maybe this only matters for egl.. https://github.com/NVIDIA/libglvnd/blob/master/src/EGL/icd_enumeration.md
<robclark> paste /var/log/Xorg.0.log?
<steev> which version of mesa do you have?
<akaWolf> steev: 24.0.1
<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 ?
<akaWolf> steev: no
<steev> can you show your mesa package contents installed on the system?
<robclark> https://paste.akawolf.org/view/HKmAT#line-92 <--- there's your problem
<akaWolf> robclark: ShadowFB?
<robclark> the line before it
<steev> are you using an xorg.conf?
<robclark> glamor init fails
<robclark> idk yet what might cause that.. but that will cause glx anything not to work
<steev> or is your user not in the video group
<steev> or whatever the drm devices are grouped
<akaWolf> steev: not using
<steev> can you show your kernel command line arguments
<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??
<akaWolf> steev: steev: initrd=\initramfs-linux.img root="UUID=149cee5f-40af-40c7-a453-2593f29f22a9" rw dtb=/sc8280xp-lenovo-thinkpad-x13s.dtb efi=novamap pd_ignore_unused clk_ignore_unused
<akaWolf> robclark: I will try to restart
<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