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)
Lucanis has joined #aarch64-laptops
<bamse> harvestz[m]: yeah, i'm using the x13s as my desktop machine now, driving my two 4k monitors
<bamse> one day i will clean up my desk enough to take a picture ;)
<steev> keep austin weird
<harvestz[m]> <bamse> "harvestz: yeah, i'm using the x1..." <- Awesome! I was considering grabbing the dual up monitor for it
FizzBuzz has joined #aarch64-laptops
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<clover[m]> Is bamse based in Austin? I'm in Houston
<bamse> clover[m]: small world :)
FizzBuzz has quit [Quit: Leaving]
<steev> clover[m]: i'm in SA :)
<bamse> GTA!
<bamse> wrong SA...
<steev> based on texas drivers... might as well be
<bamse> i prefer the texas drivers over my previous enemies on the road
<steev> hm
<steev> somehow my c630 is doing software rendering on 5.19.2
<bamse> we need to get some CI going on that device...
<steev> gnome also seems to say i have a 4.2MB drive heh
<steev> but, in good news, audio does work with 5.19.2 so that's good
<bamse> sweet, then you can play that one mp3 you can fit on your disk
<steev> gpu seems to be working on 6, so that's good, but even with srinik's patch, no audio
<steev> the weird thing is... it SEEMS like it should be work
<bamse> and you're not just on efifb because timing screwed you over while booting?
<steev> i didn't check that in 5.19.2, let me look in the log rq
<steev> weird
<steev> let me reboot back into it
<bamse> don't forget to switch dt between the two
<steev> i do :)
<steev> i think something is getting deferred
<steev> ah yes
<steev> wtf
<steev> what the heck did i break
<bamse> 88e9000.phy is the edp phy right?
<steev> i do believe so
<bamse> this is very similar to the problem i see on sc8180x
<bamse> what happens if you echo af00000.clock-controller into /sys/bus/platform/drivers/dispcc-sdm845/bind ?
<bamse> with some variation of dispcc-sdm845
<bamse> i think it's fw_devlink that spots the cyclic loop and just decides that these things should be probed later, but then never retries
<bamse> abelvesa was looking into this and saravanna is supposed to have some solution for this
<steev> ffs
derzahl has joined #aarch64-laptops
<steev> it helps to be on the c630 when i'm trying to do that
<bamse> but that said, i hit this on my c630 a few times...but only sporadically, so rebooting helped
<steev> resource temporarily unavailable
<clover[m]> Is c630 more mature in terms of feature support than x13s?
<steev> yes
<steev> it's like 4 years older too though?
<bamse> clover[m]: steev is carrying some more cruft, but i've been running mine for a few releases now with only 2 patches ontop of mainline
<bamse> clover[m]: the battery driver and the enablement of the battery driver
<steev> yeah, i carry a bunch of cruft for mine :(
<steev> Your branch is ahead of 'origin/linux-5.19.y' by 201 commits.
<bamse> but i'm hoping the maintainer will pick up the battery driver for 6.1
<bamse> looking forward to be able to just run the arch kernel starting in 6.1 :)
<steev> i'll do a clear 5.19.2 and only do the lru stuff and battery/dp
<steev> oh right
<steev> this has all the sc8180x stuff in it, that's where i hid it all
<bamse> i should post that as well, because my new sc8180x branch is awesome
<bamse> it's quite a bit snappier thanks to Molly's pinctrl fix, and the battery driver now tells me that i have a lot of battery life left :)
<bamse> and it's no longer my desktop, so i can affort rebooting it and try out new things ;)
<steev> alright, stripped out all the extra stuff, except the lru bits
<steev> well, most of the extra stuff
<steev> i need my i2c fixes :(
<steev> i think 1 of them made it in to 5.19.1 or .2, but not the other 2?
<steev> 0142-i2c-qcom-geni-Propagate-GENI_ABORT_DONE-to-geni_i2c_.patch
<steev> 0143-i2c-qcom-geni-Silence-NACK-and-GENI_TIMEOUT.patch
<steev> those ones
<steev> clover[m]: fwiw, the battery on the c630 reports 9 hours too, but, it's pretty easy to get about 28 or so
<bamse> we need to figure out how to improve that
<bamse> same things with the x13s, they are idling too warm
<steev> i think it's just what the EC reports
<steev> because now it's showing 16 hours
<bamse> just run i3status, it will improve it further
<bamse> but i don't think it should idle that warm, so there's stuff we're not scaling down, turning off etc
<steev> oh, yeah, thinkpad definitely idles too warm
<szclsya[m]> bmase: indeed, it's warmer than in windows
<steev> the c630 idles around 35-37
<steev> atm, i'm trying to figure out this stupid firmware package, debian's is super convoluted because they take the license serious
<steev> which, i get
<bamse> right, but if you idle really hard i think you should be able to do room temperature
<steev> pls no
<steev> my AC can't keep up
<steev> it still idles lower than my other devices
<bamse> hehe okay :)
<bamse> so i guess that's not the measuring stick i should be using
<steev> nah, i forgot that 35 is still > hot
<steev> it's 33 now that alacritty and btm aren't running, just sway and waybar
<bamse> we need to figure that out, alacritty consumes a ton of cpu when i'm building the kernel - on a different machine
<steev> it shouldn't consume that much, but then again, maybe
<bamse> the threadripper does produce a lot of text
<steev> that's fair
<steev> with just bottom open, alacritty uses 7% cpu on my x13s
<steev> but that makes sense to me because software rendering
<bamse> right
vkoul has joined #aarch64-laptops
mani_s has joined #aarch64-laptops
srinik has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
flowriser has joined #aarch64-laptops
<clover[m]> What's the easiest way to emulate x86 on arm64?
<szclsya[m]> systemd-binfmt
<szclsya[m]> it uses qemu so it's slow, but it's pretty painless to use
<HdkR> "Best" might be a different answer though
<HdkR> clover[m]: box86, box64, and fex-emu are viable options as well.
<steev> hm
<steev> i did something weird with my flex5g's firmware i think
<steev> bamse: where does the a640_gmu.bin file come from?
<szclsya[m]> ah box64 can be used by systemd-binfmt too, neat
<HdkR> FEX as well
<HdkR> Whoa, taste the rainbow
<steev> Apparently
<steev> I tried shoving the a680 firmwares into place
<steev> i guess it doesn't like the a680 firmware afterall
<bamse> steev: i don't know, so i'm fairly confident that you didn't get yours from me(?)
<steev> i don't know either, but i also am not sure why it's looking for a640_gmu.bin
<steev> that doesn't, afaict, exist upstream
<bamse> steev: that's because a680 is a beefed up a640
<steev> ah, that's fair
<steev> would be nice to get the 640gmu into linux-firmware at some point
<steev> if you know anyone to poke to try to get that done ;)
<steev> bamse: do you happen to know a downstream firmware repo that might have it? that seems to be the only thing i'm missing here
<bamse> no :(
<steev> also apparently i don't have the same screen as you because i splat :)
<steev> BUT
<bamse> edp-panel splat?
<steev> there's no 25% cpu
<steev> yeah
<bamse> i just ignore that splash
<bamse> exactly, there's plenty of idle cpus
<steev> oh, okay
<steev> i'll see about finding a datasheet for it
<steev> though, i don't think i've heard back from the drm list about my thinkpad panel
<steev> i thought the gmu firmware was supposed to be replaced by the zap stuff in the dts; so it shouldn't matter
<bamse> no, the sqe and gmu are based on the version, then the zap is device-specific and signed, so that we specify in dt
<steev> well using upstream a630_sqe.fw and ignoring the missing a640_gmu.bin, graphics are okay, no gpu but that's kinda expected
<bamse> if you do status = "disabled" on the gpu node you should have a at least the same, if not better, outcome
<HdkR> Is this a GPU coming online on X13s?
<steev> no, we're talking flex 5g here :(
<HdkR> Dang
<steev> i've found a possible a640_gmu.bin but i'm pretty sure this is the one i was using before now that i look through the repo
<steev> bamse: oh! something else i just realized, the touchpad isn't lagging when i'm using the wifi :D
systwi_ has joined #aarch64-laptops
systwi has quit [Ping timeout: 480 seconds]
<steev> bamse: i'm not getting battery stats here on the flex, what am i missing in my config? i definitely have the battmgr, but like clover earlier, i'm only seeing the 2 names, but unlike clover, i do have the pd-mapper and various services running
Guest580 is now known as Penguinpee
pierro78 has joined #aarch64-laptops
jelly has quit [Read error: Connection reset by peer]
<leezu> hexdump01: Have you used systemd-coredump? I'm unable to get it to work and it always fails with "Core dump to |/lib/systemd/systemd-coredump pipe failed"
<leezu> steev: have you tested your "Update meta connector types enum" mutter fix on version 42? I applied it to 42 and still face a crash when plugging in a usb-c screen in meta_fixed_16_to_int while in wayland session https://pastebin.com/WrXGygez Is that related to the crash you observed before?
<steev> leezu: i have tested it on 42, that's what is in debian testing and what kali runs
<steev> i don't see that here, but i haven't tested extensively
<leezu> Ok, thanks for letting me know. Do you have any suggestions how to debug this crash in meta_fixed_16_to_int?
<leezu> For now I'll rebuild without optimization and get a new coredump
<steev> sounds a good idea
<leezu> meta_kms_update_get_primary_plane_assignment / get_first_plane_assignment returns null
<steev> maybe poke around in the mutter gitlab and see if someone has reported similar?
<steev> that could also be similar to what travmurav[m] is dealing with (i'm not sure)
<travmurav[m]> leezu: could you hint me how did you start the session to backtrace it so I could try to reproduce
<leezu> I can reproduce the error with bare mutter 42 and also 43.beta (recently packaged in debian experimental). So simply running mutter --display-server --wayland while having the usb-c monitor plugged causes mutter to crash at start and, if started while the usb-c was plugged out, it crashes upon connecting
<leezu> travmurav[m]: I simply specify in /proc/sys/kernel/core_pattern /home/YOURNAME/core-%p-%u-%g-%s-%t-%e and set "* soft core unlimited" in /etc/security/limits.conf to enable core files. Then gdb mutter path-to-core (or with gnome-shell instead of mutter if you repro with gnome-shell)
<leezu> I've documented the issue at https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
<steev> bamse: is the adsp hack still needed? https://github.com/andersson/kernel/commit/9f63917ec8447980fbe067182fdf5c582b8f03e1 - wouldn't that stop adsp from starting?
<steev> oh, no, it always starts it, nevermind, i'm blind/dumb
<steev> bamse: ah, i think i see - service lookup failed for tms/servreg failed: -6
<steev> aha, i was missing battery info on the flex because of the lack of battmgr.jsn file, fixt
<hexdump01> leezu: i never used systemd-coredump, so cannot really help with this
<steev> woo, and with qzed's usb mp patches (slightly modified due to not applying cleanly to the new stuff), now have webcam on the flex5g as well
<jenneron[m]> pierro78: will you be able to test kernel on galaxy book s?
<bamse> steev: i merged the adsp fix in v6.0-rc1 iirc
<pierro78> @jenneron : sure , I am on debian sid I would love to test your kernel :)
<pierro78> jenneron if it s not too hard to install ;)
<jenneron[m]> pierro78: use this branch https://gitlab.com/jenneron/linux/-/tree/galaxy-book-s-5.19.0 and use galaxy-book-s_defconfig, it has working usb, keyboard, touchpad, gpu and panel
<jenneron[m]> dtb is sc8180x-samsung-galaxy-book-s.dtb
<jenneron[m]> i need i2cdetect from first i2c bus and testing modem and wifi/bt
<jenneron[m]> note that display won't work without kernel modules installed
<pierro78> jenneron I guess I can run the usual commands as in https://github.com/aarch64-laptops/debian-cdimage to build my kernel ?
<steev> bamse: oh, i'll have to looksie
<steev> bamse: fwiw, https://github.com/steev/linux/commits/sc8180x-next20220728%2Busb-mp%2Ba680 here's the stuff i threw on top of yours
<pierro78> under WSL2 as native debian is 5 times slower than windows and I guess WSL2 should be about as fast as windows ....
<pierro78> jenneron then just transfer the kernel and dtb to debian and install there ?
<jenneron[m]> i'm not sure about that, i haven't tried doing it with deb packages
<steev> pierro78: assuming there's a defconfig in that branch, you can "make deb-pkg" and just scp the linux-image deb over
<steev> and install that
<steev> oh, there is :)
<steev> you should be able to do something like (native arm64 here) make defconfig; make -j$(nproc) deb-pkg
<jenneron[m]> pierro78: build, copy kernel image and dtb to ESP partition (/boot or /boot/efi) and add something like this to your grub.cfg https://dpaste.com/C9AWZJTFA
<jenneron[m]> is your installation on UFS?
<jenneron[m]> upd: don't copy to /boot/efi, copy to /boot
<steev> bamse: oh! the patch from mani
<steev> hm, we should probably add the galaxy-book-s stuff to the dtb copier i guess
<jenneron[m]> i have no idea what is that honestly
<steev> it's something the aarch64-laptops debian installer copies over
<jenneron[m]> i see
<steev> it does copy the dtb into the esp partition, and uses dtbloader to pass it in, so you don't have to specify it each time
<steev> it's not needed if you do what you do though, and you can override it by doing what you did as well
<jenneron[m]> i'm going to rename it to sc8180x-samsung-w767.dtb for consistency with https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sdm850-samsung-w737.dts
<steev> personally i like the "common" name, more than the model
<steev> i have no idea what a samsung w767 or 737 are, but i do know what a galaxy book s and galaxybook 2 are
irl25519 has joined #aarch64-laptops
pierro78_ has joined #aarch64-laptops
<steev> bamse: with the a680 patches, i do seem to get gpu (alacritty has my nice transparency, at least)
<steev> i need to redo the usb-mp patch for the flex though, i'd modified the firmware path to point into LENOVO/82AK
<pierro78_> I am cloning your sources with git clone https://gitlab.com/jenneron/linux.git
<steev> jenneron[m]: do you get battery info? you might want to look into bamse's work on that recently
<steev> no idea if it's done the same way or not
<pierro78_> jenneron what would be the equivalent of "git checkout -b laptops-5.13 origin/laptops-5.13" ?
<steev> pierro78_: -b galaxy-book-s-5.19.0
<steev> and origin/galaxy-book-s-5.19.0
<jenneron[m]> i've not been reported about battery, i haven't tested it myself
<pierro78_> thanks
<steev> -b <local branch name> <remote/branch>
<steev> https://github.com/andersson/kernel/commits/wip/sc8180x-next-20220728 is the latest stuff for the sc8180x, i think you want/need the sbu mux, and pmic glink stuff if you wanted to try
<jenneron[m]> i currently use surface pro x tree because i need usb-mp
pierro78_ has quit [Quit: Page closed]
<pierro78> argh lost keyboard and touchpad on my galaxy book s windows with WSL2 :( ... git clone still running though and touchscreen working ... I am going to reboot as soon as git clone is finished ... really weird ... I guess I will use only jenneron's sources for now ? more simple maybe ?
<jenneron[m]> you can use git clone https://gitlab.com/jenneron/linux -b galaxy-book-s-5.19.0 --depth 1 to clone faster
<steev> jenneron[m]: yeah, you should be able to compare and contrast the patches, qzed already applies some in his tree
pierro78_ has joined #aarch64-laptops
<jenneron[m]> also, if you build in WSL, it wll be pain to copy modules
<steev> pierro78: yes, you should definitely just use jenneron[m]'s stuff
<steev> nah, he can just build a deb since he's debian
<jenneron[m]> ok
<steev> i cross build in wsl for my systems
pierro78 has quit [Remote host closed the connection]
pierro78_ has quit [Remote host closed the connection]
irl25519 has quit [Quit: irl25519]
pierro78 has joined #aarch64-laptops
pierro78_ has joined #aarch64-laptops
<pierro78_> galaxy-book-s_defconfig done .... build started ...
<jenneron[m]> i've pushed firmware files here https://gitlab.com/jenneron/firmware-samsung-galaxy-book-s
<pierro78> make LOCALVERSION="-custom" -j8 bindeb-pkg failed to build the packages ... I am trying with make LOCALVERSION="-custom" -j8 deb-pkg as suggested ... hopefully it will build packages ...
<jenneron[m]> pierro78: note that I haven't enabled UFS yet
<clover[m]> im going to make an x86 chroot (Debian buster)
<clover[m]> on my alarm install
<pierro78_> still have similar error building packages .... same as https://askubuntu.com/questions/1327749/error-in-compiling-installing-realtime-kernel-on-ubuntu-20-04-2-lts .... I am going to try suggested fix ...
<pierro78_> I was missing liblz4-tool as explained in https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/950 .. trying again ...
<szclsya[m]> steev: just tried the latest next branch, snd_soc_sc8280xp module loads without problem but alsa doesn't report a soundcard
<clover[m]> i notice in the kernel
<clover[m]> CONFIG_BINFMT_MISC=m
<clover[m]> does that mean its a module?
<HdkR> yes
<clover[m]> how do i load this module?
<HdkR> Dunno, I don't build it as a module
<clover[m]> seems to be loaded already
<clover[m]> maybe systemd-binfmt does it for me
<clover[m]> steev: what debian mirror do you use?
<clover[m]> i figure i could trust a fellow texan
<pierro78> jenneron where should I put firmware files from https://gitlab.com/jenneron/firmware-samsung-galaxy-book-s ?? sorry for stupid question ...
<jenneron[m]> pierro78: /lib/firmware/qcom/sc8180x/sm-w767
<jenneron[m]> also, take a680_gmu.bin and a680_sqe.fw from https://github.com/linux-surface/aarch64-firmware/tree/main/firmware/qcom and place them into /lib/firmware/qcom
<steev> szclsya[m]: correct
<steev> clover[m]: i dunno, whatever deb.debian.org gives me
<szclsya[m]> welp, at least the module loads without panic
<steev> i *think* at this point all we need is the ucm configs
<szclsya[m]> it should still show up in aplay -L without ucm though?