ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
djakov has joined #aarch64-laptops
<steev> ah, not codec stuff, good to know
<clover[m]> 3D surround sound (just watched a video on it)
<steev> that works in minecraft on the x13s so i guess we call it good
<steev> pushed out the 6.2.1 stuff, i'll probably create a branch similar to the other devices i do, and make it lenovo-x13s-linux-6.2.y eventually (or hell i may have and just forgotten)
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
systwi has joined #aarch64-laptops
<HdkR> clover[m]: Can you check if keyboard ghosting on Windows happens on X13s as well? I found an easy test on Linux of just holding `a`, then holding shift and seeing `A` repeat, then letting go of shift and seeing `a` not continue
<HdkR> left-shift specifically in my testing
<HdkR> Not really ghosting but breaking key repeat is already nuts
<HdkR> `[ 5] 0.00-10.00 sec 403 MBytes 338 Mbits/sec 0 sender` :(
<HdkR> steev: Anything worth upgrading to that 6.2.1 branch for?
<steev> for you... not really?
<steev> just whatever security updates came in 6.2.1
<steev> i suppose the crash on early hotplug event fix that johan mentioned
<steev> i suppose you could look through and see if any of the gpu stuff might be of interest, but most of it isn't exciting
<steev> i might try re-applying rob's deadline stuff, now that the laggy cursor issue is fixed
<steev> but it requires pulling in another patchset too, but i already have that
<HdkR> Oh, early hotplug might be interesting. Since my ideal configuration would be internal monitor disabled and only ever using external
<HdkR> Until I take it on the go anyway :P
<steev> let me test this
<steev> and if it works, i'll push and say test this instead
<HdkR> Sounds good
<steev> nothing seems immediately broken, and i dunno if it really requires other stuff, but it compiles
<steev> and works, and no laggy cursor - that said, please give it a testy test cuz you do graphics stuffs
<HdkR> Fetching
<steev> you should be able to use your same config
<HdkR> nice
<HdkR> Yep, same config worked
<steev> i forget you have build box :(
<steev> i just build my kernels on the thinkpad
<HdkR> nah, I'm building on device just so I can make install
<HdkR> Too lazy to cross-compile
<steev> o
<HdkR> `Linux ubuntu 6.2.1+ #10 SMP PREEMPT Wed Mar 1 20:17:07 PST 2023 aarch64 aarch64 aarch64 GNU/Linux`
<HdkR> Alright, it at least came back
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> jhovold: bamse: mani_s: the x13s has pcie gen4 x4 right?
<HdkR> How likely do you think I can use a riser on the WWAN port and connect gigabit ethernet to it to bypass IOMMU perf problems over USB? :P
<steev> if you can find a riser... it probably would work?
<HdkR> I did find B key riser. we'll find out in a while I guess
<steev> just use that :P
<HdkR> That's pretty sick as well
<steev> it's a 2260 though
<szclsya[m]> what's the protocol used by the wwan port? I believe I read something about it can't be used to add a ssd or something
<HdkR> It's a different key on the connector than M.2 NVMe, but it should still provide two lanes of PCIe
<szclsya[m]> ah so it's a physical form factor problem. got it
<szclsya[m]> sad that there isn't much nvme 2242 options. I think the only 2tb option is from wd which uses 2230
<HdkR> External display is working again, might have just been the restart that solved it
<jhovold> steev: that should be gen3 x4
indy has quit [Ping timeout: 480 seconds]
indy_ has joined #aarch64-laptops
<steev> that's why i'm asking - seems like the tech specs say "up to gen4" but they only sell gen4
<steev> tech specs say up to gen4, but then they only sell pcie4x4
<jhovold> that disk may be gen4 but you may not be able to use that fully
<jhovold> LnkCap: Port #0, Speed 8GT/s, Width x4
<jhovold> 8GT/s is gen3
xroumegue has quit [Ping timeout: 480 seconds]
indy_ is now known as indy
<steev> according to windows, the max link speed is 4
<steev> but it does say it's currently using 3
<steev> pci 0002:01:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0002:00:00.0 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
<jhovold> yeah, but that's the disk capability, which has been downgraded to gen3 as that's what the root complex supports
<steev> ahhh, okay, that's what i wasn't entirely sure of there
<jhovold> 0002:00:00.0 is the RC
<steev> yeah, i was just misreading the output, i thought it was saying something else was limiting it based on the second half of that output :)
shoragan has quit [Remote host closed the connection]
shoragan has joined #aarch64-laptops
leiflindholm has joined #aarch64-laptops
jkm has quit [Quit: Reconnecting]
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
mcbridematt has quit []
mcbridematt has joined #aarch64-laptops
jkm has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
<steev> srinik-: can confirm with your newest patchset (3/4 4/4) applied since already had 1/4 and 2/4 applied, no longer spams multimedia4 capture missing :) however, remoteproc now spams about ports being missing :) - not sure if they're related entirely; and the only reason it happens twice is it seems to re-init the audio stuff when gdm/mutter crashes enabling external display
<steev> robclark: btw... if you're near a CrOS checkout... ;)
<srinik-> steev: i have fixes in ucm2 too, so please pick them as well
<steev> oh good to know
<steev> will do, i normally do check that and forgot
<srinik-> steev: with that you should see the profile switching work automatically once headset is plugged in
<steev> oh nice
<srinik-> steev: also 2xdmic on panel works much better. I will chase the pop sound issues next
<srinik-> steev: ucm2 PR is also sent now,
<steev> ohh that's even better
<robclark> steev: ??
<steev> robclark: the hack in the older kernel tree re: planes
<steev> 22:35:48 <robclark> if you are interested in downstream kernel hacks to work around broken userspace I can probably find you something that we have since reverted in CrOS.. since we encountered these same broken assumptions
<robclark> ahh, right
<robclark> on sec
<steev> no rush, i'm chasing down the ucm stuff at the moment to verify things for srini :)
<robclark> steev: https: //
<steev> wow that was quick
<bamse> jhovold, abelvesa: i didn't convince myself that my patch wasn't needed, but i couldn't come up with a proof of how it can happen...
hightower2 has joined #aarch64-laptops
<travmurav[m]> \o/ msm crippling hack works for mutter
<hexdump01> travmurav[m]: while you are around :) ... on your aspire 1 do you have any pd-mapper json config files? if yes, do you have them online anywhere to take a look at them?
<travmurav[m]> they were besides the fw blobs
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> travmurav[m]: oh - so i should search for them on windows?
<travmurav[m]> yep, *.jsn they were alongside mbns iirc
<hexdump0815> cool - thanks a lot ... maybe one more question: you mentioned that you re'ed the ec to get your battery hack working - how did you re it?
<travmurav[m]> I RE'd the dsdt code
<travmurav[m]> that is, the implementation for "ACPI based (battery|charger|lid|w/e)" is the dsdt code, interpreted by the OS
<travmurav[m]> there is a spec on what functions do what but otherwise it was tying to make sense of messy quanta code and poling into the ec with i2ctransfer
<travmurav[m]> I think I vaguely remember sammy implementing it as an os driver though so not sure how helpful that advice is for you...
<travmurav[m]> maybe you would also be more lucky with trying to dump some ec fw update from the efi and throwing it into ghidra
<steev> travmurav[m]: oh nice, i have only looked at it
<travmurav[m]> didn't work for me sadly as the arch seemed dubious and I couldn't find anything that would decode the instructions
<hexdump0815> ok ... i guess quite a bit experience is required to really get somewhere with this ... i'm just thinking about the samsung galaxy book go which seems to have backlight and battery controlled via ec maybe and in the dsl there are multiple i2c related to something which looks like ec
<travmurav[m]> do you have the dsdt dump?
<travmurav[m]> steev: fwiw I hand applied it since I don't know how to let git am do a manual merge resolution:
<hexdump0815> looks like the dsdt dump has never been merged:
<hexdump0815> i compared it to my own dump and they are the same
<travmurav[m]> seems like EMEC is the ec
<travmurav[m]> so would have to see what it has and how other things read it
<hexdump0815> yes and i2c2,4,5,7 seem to be related to it
<travmurav[m]> looksl ike there is a huge buffer EMEC.EMOP that something updates somehow and there are all the cool fields you;d want
<travmurav[m]> so hopefully there is a way to i2ctransfer it out from the ec
<travmurav[m]> if one understands how the acpi code does it xD
<hexdump0815> that is a good pointer already - looks like i have to learn a bit more about acpi then :)
<hexdump0815> do you see anything related to the backlight in there as well?
<steev> travmurav[m]: yeah, I just looked over the hack, I haven’t applied it because work things
<travmurav[m]> hexdump0815: maybe CBLN, not sure
<travmurav[m]> this is a purely name based guess though
<hexdump0815> there is also a large _ROM section in the dsl which has some backlight strings in them which i found somewhere in qcom bsp code - can this be of any help?
<hexdump0815> i also saw EMEC.AVBL
<travmurav[m]> if it's xml stuff then is probably for the qcom's equivalent of downstream dsi init sequences
<hexdump0815> yes - i think it was this in the code i found
<travmurav[m]> Are you sure the backlight is not just on the bridge pwm as on other devices?
<travmurav[m]> ot there is a dedicated enable/disable?
<hexdump0815> i tried to configure it like you did on the aspire 1 but it did not work - let me check how i tried it
<travmurav[m]> ah sad
<travmurav[m]> um
<travmurav[m]> so the backlight level control is not there I suppose then?
<hexdump0815> this is my wip dts which is based on your aspire 1 dts with which i at least have the gpu working (thanks to your very good preparations):
<hexdump0815> something seems to still be a bit off as after booting i see the penguins and a bit of console until i guess drm takes over and then i have random noise on the screen until xorg starts
<bamse> steev, amstan; what's missing for orientation switching is the code in the phy driver which reacts on the (existing) notification...
<hexdump0815> in xorg everything is fine again and freedreno works perfectly fine ... looks a bit like an initialisation problem to me, i.e. xorg does init something properly then (but i might be completely off)
<travmurav[m]> the noise is maybe for the time between the gpu/bridge reset and drm loading all the drivers, but it can't hide it from you with no backlight control
<hexdump0815> travmurav[m]: i have a panel backlight control in /sys, but it has no effect on the backlight
<travmurav[m]> well this is probably from the bridge setup that leads nowhere
<hexdump0815> travmurav[m]: that sounds like a good explaination for the noise - so looks like i do not have to investigate further into that and rather focus on the backlight
<travmurav[m]> can probably reduce it by adding the msm + all dependencies into the initfs
<travmurav[m]> hexdump0815: do you have some evidence the EC controls the backlight?
<hexdump0815> travmurav[m]: no - not at all, was just my (limited) guess ... i would be happy if not
<travmurav[m]> Sadly I don't have much of "hw recon" tips for windows given I was lucky to have schematics for the device
<travmurav[m]> I suppose if poking that pwm as-is didn't work, then there might be some other pwm source they use
<travmurav[m]> Actually
<travmurav[m]> the xml in your case is BacklightType=1 and says something abput pmic vs aspire1 having type=2
<travmurav[m]> so maybe they use pmic pwm instead
<travmurav[m]> cool
<hexdump0815> this is the dmesg btw.:
<travmurav[m]> (LM80-P0337-1 is a public document)
<travmurav[m]> hexdump0815: I guess dump the xml then follow "Display Drivers (ACPI and XML) Configuration Guide" chapter 9.2 to understand what it means
<hexdump0815> travmurav[m]: thanks a lot - that is a lot of good new input will have to look at all this in detail and will report here if anything comes out of it
<steev> travmurav[m]: yep, works here on thinkpad as well
<steev> also manually applied because i was too lazy to grab the patch from gerrit, and i may have gone overkill or put it in the wrong spot in the dts but mh
<travmurav[m]> Now the most important thing is to still push GNOME to fix it
<steev> oh absolutely, we might be able to get away with just a little check that the plane isn't already assigned? in that function
<travmurav[m]> steev: well this is why I linked mine so you could just curl | git am :)
<steev> ohhh i completely skipped over it
<steev> ohhh
<steev> i see what you did
<steev> mine still forces enabling the hack in the dts
<steev> i suppose yours is better, can do that
<travmurav[m]> The dts prop disables the hack tho afaiu, so I've dropped it
<travmurav[m]> (the "except" part of the original commit message)
<steev> well
<steev> it may be possible that i fucked up the logic... would not be the first time
<travmurav[m]> As long as it works :)
<steev> was what i did (uncommitted) - i'll drop mine ad grab yours and use itinstead
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<clover[m]> did someone find a fix for wayland mutter dying with on external monitor?
<clover[m]> with on lol
<ndec> clover[m]: lumag found the root cause, but I don't think there is a fix yet.
falk689 has quit [Quit: No Ping reply in 180 seconds.]
falk689 has joined #aarch64-laptops
<steev> fix no, workaround/hack that gimps the msm drm driver, yes
<steev> i thought dmitry used to hang out in here, but apparently he doesn't anymore
<steev> travmurav[m]: yep, with yours that's fine, i wonder where i screwed up that i needed the dts bits to enable it instead of disable it
<steev> i probably overlooked a ! somewhere
<steev> i was trying to patch up powershell empire at the same time, so probably missed something in the original patch
<steev> if i read dmitry's stuff correctly, we really just need to add a check in there that the crtc isn't already assigned
<steev> travmurav[m]: thanks for doing that :)
<clover[m]> does anyone know how to fix speaker playback when it goes on the fritz. the only fix i know is reboot
falk689_ has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]
<steev> clover[m]: oh, there's some updates
<ardb> on c630 all i get is clickety click
<steev> ardb: yeah, it broke around 6.0 :(
<steev> i get audio but it's very clicky
<ardb> it worked a bit better before
<ardb> but now it's completely b0rked
<steev> let me see
<steev> clover[m]: you want the 3 latest patches from
<steev> 2 are audio fixes, and the 1 is the mutter crash workaround
<steev> my c630 isn't on, lemme go do that - one thing else is that suspend seems broken on it now, it never wakes up and nothing shows up in the logs
<clover[m]> Nice! Trying
falk689_ has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops