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
<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 [resistance.oftc.net coherence.oftc.net]
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 :) https://paste.debian.net/hidden/c9055e90/ - 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 :)
<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>
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>
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]>
(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