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)
<steev>
maybe the picture is bad and my eyes just see what they want :P
echanude has joined #aarch64-laptops
<HdkR>
bamse: Tricky, I'll give that steam guard path a retry and see if something broke
<HdkR>
steev: Do you know how the grub from the boot partition understands to pull the grub.cfg from the next partition without configuration?
<steev>
nope :)
<steev>
probably some code somewhere
<HdkR>
The magic bewilders and confuses me
<robclark>
"probably some code somewhere" is an answer to a great many questions ;-)
<qzed>
IIRC you can build a config into grub. That config can then just be something that tells grub to search for the drive containing the path /boot/grub/grub.cfg or something like that, which it then sources
<HdkR>
Does it actually scan partitions to find it?
<steev>
robclark: but re: the vsync.. why would it only affect Xorg?
<robclark>
because xorg is using legacy cursor ioctls which we have to emulated by setting a timer to fire shortly before start of vblank period to flush changes to hw
<robclark>
so totally makes sense that it only effects xorg
<steev>
ahh
<steev>
i guess that's also what made the cursor occasionally jump instead of lag
<robclark>
yeah, it's very sensitive to calculating the time of start of vblank period
<robclark>
annoyingly CrOS compositor also uses legacy cursor api.. but things with that patch seemed to be working properly there.. I'll look again tomorrow (didn't have time today) but it is important for other reasons that the vblank helper can correctly calc the start of the vbl deadline
<steev>
if i knew what to even remotely look for, for the reason why mutter crashes when we try to use external, it would be a moot point
<robclark>
I thought there was a mutter/g-s thing that you already fixed
<robclark>
oh.. I guess it is another case of msm being less crippled than intel surfacing bad userspace assumptions again ;-)
<steev>
nope... i fixed other things...
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<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
<steev>
i mean... i'm not *personally* against it... i'm down with any hack that makes a ssytem usable
<robclark>
not in front of CrOS git trees atm but tomorrow (it doesn't hurt to ping me to remind me) I'll point you at downstream kernel hacks we used to work around similar issues
<HdkR>
steev: 2230->2242 adapters exist which /might/ work
<steev>
i'm not in any rush :) that bug has been open 6 months...
<steev>
and lumag brings up a good point, asking why mutter cares about primary plane... it would be nice if someone from upstream would respond
<jhovold>
the race is definetely still there in 6.2, but may have been fixed in 6.3
<jhovold>
or rather, he did find a workaround, but then convinced himself it wasn't needed, possibly because bames tends to run linux-next where the hotplug detect code has been reworked:
<jhovold>
abelvesa: if you got a decent reproducer, can you try moving the initialising like bamse suggested here:
<abelvesa>
jhovold: thing is I only managed to repro it once on latest boot
<abelvesa>
jhovold: I'll reboot a few more times to see if repros again
<jhovold>
yeah, it seems to depend on when you userspace starts the pd-mapper. Was able to trigger it four times in a row with one build and got some logs, but now it's gone again
<jhovold>
so the drm driver is definitely buggy as in 6.2 it enabled hotplug notifications before everything has been set up (hence the NULL deref)
<jhovold>
and it seems that bamse's pmic-glink-altmode driver is buggy as it is sending hotplug notifications also when not having any external display connected
<jhovold>
and/or it's the fw that buggy
<abelvesa>
yep, reproduces 4 times out of 4
<jhovold>
i can reproduce it on the crd where I got a serial console, which helps to say the least
<abelvesa>
funny thing is, when I let the grub timeout to be reached, it reproduces every time
<abelvesa>
when I select an entry before timeout it reached, it never reproduces
<jhovold>
heh, fscking heisenbug
<mothenjoyer69>
<jenneron[m]> "by problem i mean embedded..." <- do you happen to have an ACPI dump? or know of anyone who may be able to provide one?
<abelvesa>
jhovold: I'll start digging into it then
<mothenjoyer69>
or if any Galaxy Book Go 5G owners (8cx variant) could get an ACPI dump for me, that would be helpful. i have a strong suspicion that it is going to have a lot in common with the galaxy book s but i can't seem to find anything online
<jhovold>
abelvesa: that's ok, I'm on it. But if you can try bamse's workaround from above and have a decent repro then see if that alone is enough to address this
<abelvesa>
jhovold: ok then, will try bamse's workaround
<jhovold>
abelvesa: are you still able to ssh into machine after you hit the NULL deref?
<jhovold>
my USB ethernet never probes, and the serial getty is not started either when I've hit it
<jhovold>
and the screen remains black as ndec reported...
<jhovold>
abelvesa: and are you using an external display or not? I don't and still hit it as I mentioned above.
<jhovold>
hmm. ok, so the pmic-glink altmode driver always sends notifications, in my case a disconnected event
<abelvesa>
jhovold: nope, can't ssh into it
<jhovold>
guess that was the last piece of the puzzle
<jhovold>
how did you get the log out?
<abelvesa>
journalctl
<abelvesa>
I can't ssh into it because the eth is over typec
<jhovold>
heh, guess ndec never checked that (as lumag suggested)
<jhovold>
same here
<jhovold>
abelvesa: I'll prepare a fix, and then we can see if we need to carry it out-of-tree or if can get it into 6.3 and backported even with the reworked hotplug code in there
<abelvesa>
jhovold: thanks, please cc me on it as well, I can test it
<jhovold>
i will, thanks
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<abelvesa>
jhovold: BTW, with bamse's workaround, I can't repro it anymore
<jhovold>
abelvesa: thanks for confirming
<jhovold>
i have a reliable reproducer now too
<HdkR>
oop, I noticed external display isn't working anymore on X13s. Regression or do I just need to reboot the device?
<danielt>
Which kernel version? There was a display regression recently but it has been fixed.
<HdkR>
Rocking steev's 6.2 branch
<HdkR>
I believe the rc branch was the one that had it working but I guess something changed between those time periods
<amstan>
that's typical behavior for something not hooked up right with the lanes
<amstan>
the AP needs to be told which orientation stuff is from whomever talks PD
<steev>
not to disparage pine64, because i love their stuff, but lets not pretend their hardware is wired up correctly either... could be something on their end
<amstan>
no, i wouldn't blame the adaptor, probably your laptop/drivers
<amstan>
i mean.... it's possible it's the adaptor, but given we're all in this channel for a reason ;)
<steev>
lol
<steev>
it's definitely the driver, i just dunno/don't have the skill to fix it; bamse said something about one of his other trees probably has the fix, i just haven't gone through the backlog to see which one it was to compare
<amstan>
extcon is the old way of doing it, there might be some typec apis now instead
<amstan>
on your device the other end (non-dp ip block) is probably not an EC but something else that also speaks PD, maybe the tcpc directly, or knowing qcom maybe the pmic
kettenis has joined #aarch64-laptops
<steev>
i couldn't say :(
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<robclark>
steev: one char typo in the "cleaned up" version of my patch was responsible for your cursor badness: