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
KREYREN_oftc has joined #aarch64-laptops
hexdump0815 has quit [Remote host closed the connection]
hexdump0815 has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
jglathe_ has quit [Remote host closed the connection]
jglathe_ has joined #aarch64-laptops
agl7-x13s-debian has joined #aarch64-laptops
agl7-x13s-debian is now known as agl-x13s-debian
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
possiblemeatball has quit [Ping timeout: 480 seconds]
agl7-x13s-debian has joined #aarch64-laptops
agl-x13s-debian has quit [Read error: Connection reset by peer]
<Segfault[m]>
hmm, i tried my SN740 again and got another dropout after a while
<Segfault[m]>
i don't think this ssd has apst issues with other machines
<Segfault[m]>
windows bsods immediately trying to boot from this drive so it may be a hardware bug
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
agl7-x13s-debian_ has joined #aarch64-laptops
agl7-x13s-debian has quit [Ping timeout: 480 seconds]
<steev>
is it on the latest firmware? i see the occasional correctable error, but never the dropout, and i was just in windows for a bit earlier as well
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #aarch64-laptops
<Segfault[m]>
yeah latest firmware, kernel from jhovolds 6.9-rc4 tree
<Segfault[m]>
this same setup was perfectly stable with the stock ssd
<Segfault[m]>
on the upside the pcie driver isn't totally dying when it happens now, in the past when i tried this ssd it'd occasionally error but instead of properly logging things the whole pcie driver would freak out which would also kill wifi/cellular and eventually cause a kernel panic
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
agl has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit []
martiert has quit [Quit: WeeChat 4.2.1]
martiert has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
paddymahoney has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.2.2]
martiert has joined #aarch64-laptops
agl7-x13s-debian has joined #aarch64-laptops
agl7-x13s-debian_ has quit [Ping timeout: 480 seconds]
agl7-x13s-debian has quit [Quit: Leaving]
jglathe_ has quit [Remote host closed the connection]
jglathe_ has joined #aarch64-laptops
<jhovold>
steev: please report any issues you run into with the dp audio series on the list so we can get that sorted before it is merged
<travmurav[m]>
Was the "error if no cable" thing reworked for dp audio? Somehow I can't find that series in linux-arm-msm...
<travmurav[m]>
ah see it on asla-devel
<travmurav[m]>
ugh I guess it doesn't use the dp port thing in the msm driver :S
<jhovold>
travmurav[m]: I've only skimmed the series so far, but Srini mentioned that he worked around some implementation limitation using some muxing so that you only get either DP output or Speaker output
<jhovold>
I'm was hoping he'd get that fixed before posting
<travmurav[m]>
interesting
<jhovold>
travmurav[m]: do you have access to some non sc8280xp qcom boards?
WaseemAlkurdi has joined #aarch64-laptops
<travmurav[m]>
I only have sc7180 woa
<travmurav[m]>
on which DP audio works fine except ^ quirk
<travmurav[m]>
well, also some old 8916 devices but probably "too old" xD
<jhovold>
apparently some qcom bluetooth controllers use a different default address than 00:00:00:00:5a:ad
<travmurav[m]>
but I think it was still setting 0000 on first bytes for me, not 3998
<travmurav[m]>
though this is the linux-firmware qca blobs, maybe cros has custom ones?
<jhovold>
true, could be something like that
svarbanov has joined #aarch64-laptops
<jhovold>
travmurav[m]: and thanks for the pointer to the dp quirk, still haven't look at the details here, but I'd really like to avoid enforcing that muxing
<travmurav[m]>
jhovold: for aspire1 the DP stuff is fully upstream, and this only causes problems if the cable wasn't plugged when i.e. PA started and parsed UCM (since it triest the port, gets -enival and drops the whole ucm profile), if the cable is in when ucm is parsed, dp audio just works
<Segfault[m]>
<Segfault[m]> "dmesg.txt" <- ok so i thought this was an aspm bug, they're not exactly uncommon, but after disabling it i've come across a new failure mode, i'll send a kernel log in a sec
<jhovold>
travmurav[m]: yeah, that's problem srini tried to work around by forcing the muxing between speaker, dp1 and dp2 (i.e. only one device can be used at a time)
<jhovold>
PA would only probe the speaker and succeed and boot this way, later you can mux in dp, but this way you restrict use cases that may want to use some or all of those output in parallel (if they exist)
<travmurav[m]>
I'd assume it can be solved by making the dp_audio cache accesses until the hw is clocked tbh, not sure how hard it is, but yes I'm also working it around by only allowing UCM profile to appear if the calble is plugged for now
<jhovold>
yes, it definitely sounds like something that can be handled in the driver in some way
<travmurav[m]>
Ah I see, I guess if the dp is not attached when the profile probes, it would never einval but if we attach a dedicated MM to each port then the dp ports will fail
<travmurav[m]>
That's kinda clever actually given the limitation we have, though probably still rather a "workaround" than a "solution" since we hope PA just doesn't run enable sequence when it probes the port in that case...
<travmurav[m]>
hm
<travmurav[m]>
I wonder if we can just put dedicate MM enable/disable to each profile instead of using the same one for all three there...
<travmurav[m]>
or not sure if PA doesn't try the other profile /because/ it's marked as conflicting...
<travmurav[m]>
meh I guess it doesn't work like I thought it does
f_ has joined #aarch64-laptops
possiblemeatball has quit [Ping timeout: 480 seconds]
<steev>
hm, yeah, i'm not a fan of the current implementation, mostly because the dp devices show up even if nothing is plugged in, in terms of speakers
<steev>
but also because i haven't ogtten it to work, and yeah jhovold i'm planning to send an email but i wasn't cc'd on v2 nor was linux-msm, so i gotta do the git sending an email thing and need to find free time
svarbanov has quit [Ping timeout: 480 seconds]
<Jasper[m]>
@HdkR I'm running into an issue where I cannot compile FEX on Fedora
<Jasper[m]>
Neither HEAD of main nor the latest release
<HdkR>
Jasper[m]: clang-18 issue maybe? I assume that's the version of clang you have
craftyguy has quit [Remote host closed the connection]
<HdkR>
Looks like we're missing an `#include <algorithm>` in that file
<HdkR>
So might be a libstdc++-14 change even
craftyguy has joined #aarch64-laptops
<Jasper[m]>
HdkR: 18.1.1
<Jasper[m]>
HdkR: 14.0.1
<Jasper[m]>
There's also the warnings at the bottom, but I don't think it fails on that
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<travmurav[m]>
steev: dp ports appear/disapper fine with the existing jack detection for me fwiw
<travmurav[m]>
as in, with proper profile and after PA was started with the cable, I can unplug it for it to switch to speakers and hide dp; and plug it back so it switches back to dp that appears again
<HdkR>
Jasper[m]: The warnings are benign, some changes to libstdc++ caused them and just an annoyance if we want to get rid of them
<steev>
travmurav[m]: on pipewire, i just always see "speaker playback"/"hdmi/dp 0 playback"/"hdmi/dp 1 playback"
f_ has quit [Ping timeout: 480 seconds]
<z3ntu>
travmurav I think sc8280xp machine driver doesn't have HDMI jack support, maybe that's that?
<travmurav[m]>
Luca Weiss: afaict jack is added in the Srini's series too
<steev>
travmurav[m]: as in, i have booted without anything plugged in, and am seeing the dp devices listed
<travmurav[m]>
and it's hooked up
<travmurav[m]>
so not sure why it doesn't work
<travmurav[m]>
well, on sc7180 it's perfectly fine so I assume one can make it work on 8280 too :>
<HdkR>
Jasper[m]: Compile error has been fixed in FEX upstream now
<Jasper[m]>
<HdkR> "Jasper: Compile error has been..." <- Thanks! Will walk through building again to see if I run into any other snags
jhovold has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
<steev>
travmurav[m]: z3ntu yeah, pipewire definitely doesn't seem to respect/honor/know about the hdmi jack support of the patch. have tried changing to "ProAudio" in pavucontrol but that didn't change anything.
svarbanov has joined #aarch64-laptops
KREYREN_oftc has quit [Write error: connection closed]
KREYREN_oftc has joined #aarch64-laptops
<Jasper[m]>
<HdkR> "Jasper: Compile error has been..." <- Building now works and I can start steam again. One last question though. Any tips on updating the rootfs itself? I think there may be some mesa updates missing.
<Jasper[m]>
iirc it's fedora, but custom
<Jasper[m]>
don't remember exactly
<HdkR>
Jasper[m]: You can rerun FEXRootFSFetcher to pull the latest image which has Mesa 24.0. If you need something unreleased then that'll require self building
<Jasper[m]>
Ah, will try tomorrow then, thanks for now!