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>
i think armbian might also have them somewhere in their tree because they also do it
<qzed>
might look into this but at the moment I'm fine with hacking together the tools from the stock kernel... it's temporary anyways
<steev>
i usually just point the build/source symlinks to a git checkout, but i know that isn't for everyone
<robclark>
HdkR: a bit of trial/error w/ freedreno_devices.py should get a690 working.. I had assumed it was basically what a680 was to a640 relative to a660.. but other observations indicate it might actually be really close to a680.. idk.. I guess which a6xx sub-gen it is should be clear once kernel side is in place?
<robclark>
(or rather, I guess the freedreno_devices.py bit only helps with the userspace half of it)
<HdkR>
hm
<HdkR>
I guess I'll order one for now and get four more if it works without hassle
<steev>
so what i'm hearing is, "just make 690 point at 680 stuff and see what blows up"
<HdkR>
Nabbed one for testing
<robclark>
it's worth a try.. I forget what the situation is on kernel side
<robclark>
but I guess bamse knows of a kernel branch somewhere w/ downstream a690?
derzahl has quit [Remote host closed the connection]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<bamse>
steev: per qzed on sq1 the "a690" seems to just be an a680...
<qzed>
I'm not sure though if the spx has a "real" a690...
<bamse>
steev: but looking at the downstream sa8295p sources the a690 in 8cx gen 3 is a a660 derrivative
<robclark>
the userspace part of it should be mostly just deciding if it is a660 or a640 derivative.. I guess the kernel side of it involves a bit more actual keyboard hammering
<bamse>
i share that expectation
<bamse>
just haven't had a need for polygons, things works well enough without them :)
<HdkR>
Sadly I have maximum need for polygons
<HdkR>
:(
jhovold has joined #aarch64-laptops
<steev>
you only get half polygons
<amstan>
halflygon
<steev>
new band namy
<szclsya[m]>
I just installed alarm on the internal ssd of my x13s, works fine
<bamse>
szclsya[m]: sweet, welcome to the club :)
<steev>
say the phrase! say the phrase!
<szclsya[m]>
I use arch on x13s btw (x
<steev>
glad it's working for ya
<steev>
now get to kernel hacking :P
<steev>
jhovold: speaking of kernel hacking... will mdss bits be going to mainline soonishly?
<steev>
szclsya[m]: oh, since you have one... does the touchscreen work?
<szclsya[m]>
Lemme setup my desktop real quick
<szclsya[m]>
Doesn't seem to work under sway
<bamse>
steev: i was hoping to have posted the mdss pieces already...definitely will get there soon
<steev>
bamse: ah, i thought they were coming from johan, sorry for the ping :(
<bamse>
steev: nah, they are my workings...
<szclsya[m]>
wow alacritty is slow af...
<steev>
working fine here :(
<szclsya[m]>
konsole is fine though
<szclsya[m]>
weird, seems that sway is not using its native hidpi capabilities here. after I scale everything seems to just get Nearest-neighbor-ed
<klardotsh>
NN scaling in sway usually implies xwayland is involved somewhere in the application's call stack
<klardotsh>
vs native wayland
<szclsya[m]>
I think I don't even have xwayland installed though
<szclsya[m]>
the whole interface is messed up
<szclsya[m]>
touchpad also doesn't seems work, fortunately I like trackpoints
<HdkR>
alacritty on software rendering doesn't sound the best
falk689 has quit [Remote host closed the connection]
iivanov__ has joined #aarch64-laptops
iivanov__ has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<clover[m]>
"This means your firmware does not support the device tree fixup protocol, which sd-boot relies upon for device tree support. (dtb= cmdline is handled directly by the kernel and therefore works)"
<clover[m]>
So does that mean this is all lenovo's fault? Lol
<bamse>
clover[m]: what is "the device tree fixup protocol"?
<clover[m]>
i guess its a way for the firmware to make tweaks to the device tree if it needs to?
<qzed>
clover: the grub devicetree command does work though?
<bamse>
clover[m]: if you could point to some concrete thing missing that would be useful
<bamse>
clover[m]: in the context of us already discussing devicetree loading with qcom
<clover[m]>
pretty sure people in this channel use the grub devicetree command and it works fine, but maybe it doesnt use the same 'device tree fixup protocol' thing that sd-boot uses
<robclark>
if someone could point to what the dt fixup protocol is, it could probably be added to DtbLoader
<szclsya[m]>
<qzed> "clover: the grub devicetree..." <- I'm currently using this route. Works
<qzed>
makes me think that systemd-boot should either do whatever grub is doing in case that protocol isn't available or that there's a bug in systemd-boot...
<robclark>
yeah, if protocol isn't supported it should just skip that step... that said, a no-op implementation of the protocol shouldn't be too hard (and could be useful if we ever do have to deal with fixups for different production runs, etc)
<clover[m]>
makes sence to me, i left a comment mirroring this sentiment on the issue
<bamse>
so the fixup protocol has a single method of "Fixup()"...i thought the dtb was supposed to be installed with all such Fixups already applied
<bamse>
robclark: i'd prefer if the caller treated that protocol as optional...as i'm aiming to remove the dtbloader...
<bamse>
ohh, it's to fix up the installed dtb for cases when the dtb is loaded by some 3rd party step
<bamse>
well, my goal stands with trying to get rid of the need
abelvesa has quit [Ping timeout: 480 seconds]
abelvesa has joined #aarch64-laptops
<robclark>
I guess sooner or later you'll have to deal with the fact that not all of ${whichever_laptop_model} are actually the same.. that has definitely been true so far on the chromebook side of things, if you look at all the sku's and rev's..
<HdkR>
x13s will be here tomorrow. Tinkering quite quickly I guess
<jhovold>
steev: thanks, guess updating the dtb from your branch should do the trick for the alt touchpad
<steev>
ill build your stuff tonight when i'm "off work" and can look again and give it a whirl
<jhovold>
sounds good
<steev>
jhovold: since you're marking wakeups... suspend works?
<steev>
or should work
* szclsya[m]
just realized I didn't compile my kernel with md4 and now I can't use eduroam because mschapv2 needs md4
<jhovold>
steev: no, not yet. Works to some extent, but issues with USB and PCIe.
<steev>
jhovold: ah, okay, makes sense - qzed is having similar issues with the spx
<steev>
szclsya[m]: ah, crud, i forgot to go over the defconfig, i'll try to make some time for that tonight as well
<steev>
jhovold: decided to do it on my lunch break - i added in my 300MHz (already submitted upstream), and the backlight - https://paste.debian.net/1247706 nothing seems amiss more than usual (i don't have the touchpad that szclsya[m] has, nor do i have a touchscreen - thus the bcd errors, i wonder if there's some way to mark them as optional so it doesn't spit those errors out when they aren't supposed to be there.. then again, no idea how
<steev>
to tell it which one is supposed to and which isn't)
<szclsya[m]>
jhovold: touchpad patch works, able to enable tap in sway
<szclsya[m]>
two finger scroll works too, no way to test more sophisticated gestures with sway though
<steev>
that's awesome to hear
<clover[m]>
w00t
<steev>
dianders: i *think* i've found it - i believe i have an IVO M133NW4J (not which which revision)
<bamse>
yeah, it looks just like the other platforms...some qca thing on uart
<steev>
i'd assume as long as we have the correct uart and firmware, it should work
<bamse>
hence my ask if someone has tried to plug those things in there ;)
<steev>
taking a quick glance, it looks like, just qup2_uart17 in the dtsi so... i could probably poke at it later
<steev>
although i'd just have to guess the gpios
<bamse>
what do we need? the uart pins?
<steev>
comparing to the c630, pins for pinmux, cts, rts-tx and rx
<bamse>
that would be gpio121, gpio122, gpio123 and gpio124
<bamse>
and gpio133 is "bt enable"
<steev>
noted
<steev>
dianders: i can't download it even with my account. i don't have their silly currency, and i'm not about to pay :(
<steev>
and i don't feel like giving them my kali email
<dianders>
steev: oh well. You could always just put up a rough guess with a comment saying that it was found by trial and not by datasheet so you could at least get rid of the warning...
<steev>
yeah, that's what i plan
<steev>
Lenovo ThinkBook 13s G2
<steev>
apparently that has the same display
<clover[m]>
what are you trying to do with the x13s screen now, steev?
<steev>
clover[m]: my thinkpad has a different panel than everyone else's so trying to put the timings in :)
<steev>
you can see in my dmesg output - https://paste.debian.net/1247706 - search for IVO, and you end up with [ 7.676066] panel-simple-dp-aux aux-aea0000.displayport-controller: Unknown panel IVO 0x854b, using conservative timings; basically, it's to get rid of the splat that dianders put in the sauces to make sure we get panel timings in there when needed and off the very conservative ones so that panels all just work
<steev>
definitely gonna have to guess... there are only 3 links when you search for 'IVO M133NW4J "datasheet"' and alas, the russian link does not have it either