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> from reading it, it should just be enabled for all arm64 ?
<robclark> not sure if it is upstream *yet*.. but haven't checked recently
<robclark> we are using it in CrOS kernels
<steev> ah, yeah, it's still not :(
<steev> ah, found it, it's up to v13 now :)
<robclark> there might be some other distros carrying it downstream.. but I expect it to eventually land upstream.. it's good stuff
<steev> yeah, debian won't carry it until it's in -next and even then, you gotta make it worth while
<steev> lets see if b4 will work its magic
<steev> ah, looks like there will be a v14, so maybe 5.21?
<steev> that said, looks like it applies cleanly to 5.19.0 so... here we go
<robclark> I kinda suspect that there will be as many versions as it takes.. afaiu both cros and android are using it
<steev> that's what i read as well
<steev> but, i might as well give it a spin as well :P
<leezu> Re the chromium 97 ozone wayland and gpu acceleration discussion: unfortunately it seems that keyboard IME support for non-latin inputs is broken/not yet supported with ozone wayland platform. Do you have any ideas about fixing the gpu acceleration on ozone x11 / xwayland?
<robclark> hmm, not immediately sure what input would have to do w/ gpu accel.. but also won't claim to be a chrome/ium expert.. I've just tinkered a bit with the gpu sandbox stuff when that was needed by a newer mesa (but that was probably prior to 97)
<leezu> No worries. I don't mean that IME and GPU accel is related, but that GPU accel is broken for me on ozone x11 and IME is unsupported on ozone wayland. But as workaround I can input non-latin stuff in a separate text editor window and copy over to chromium until either issue is fixed.
<robclark> ahh, gotcha.. I started running the khronos webgl conformance thing y'day on both 7c chromebook and x86 thing and both where showing a lot of similar/same fails..but gave up and killed it before it finished (it seems to take a long time).. I guess the "beta" label for the tests applies rather than indicating that something in browser or driver is broken?
<steev> robclark: do you happen to know any cros devices on 5.10?
<steev> sadly, i recently got rid of my cros chroot
<robclark> steev: I think new mtk things are on 5.10.. qc things moving to 5.15 soonish
<steev> i'm trying to find the lru stuff in the cros kernel branches :D
<robclark> it should defn be in 5.4 and 5.10 branch.. I assume by now it is in 5.15 branch?
<steev> oh, derp, i'm looking in 5.15, not 5.10
<steev> i think i found them, or most of them :)
<steev> thanks
<leezu> ci
FizzBuzz has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> leezu: if there isn’t a debian bug about chromium on wayland being broken, would you mind opening one?
<steev> I’m assuming you’re on debian anyway
<steev> iiiiiiiiiiinteresting
<steev> apparently, my audio issue on the c630 was due to the old interconnect patchset
jhovold has joined #aarch64-laptops
FizzBuzz has quit [Quit: Leaving]
iivanov has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
djakov has quit [Remote host closed the connection]
matthias_bgg has quit [Quit: Leaving]
djakov has joined #aarch64-laptops
djakov has quit [Remote host closed the connection]
djakov has joined #aarch64-laptops
pundir_ is now known as pundir
<leezu> steev: there is one existing bug related to chromium backports being broken on aarch64, possibly due to use of older clang https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006457 and I've opened a new bug regarding the Ozone issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016438
<leezu> I also got in touch with the Firefox Graphics team regarding the "glxtest: process failed (received signal 11)
<leezu> but it's currently blocked on missing debug symbols for /usr/lib/firefox/libxul.so for which I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016459
matthias_bgg has joined #aarch64-laptops
jlinton_ has joined #aarch64-laptops
jlinton_ has quit [Ping timeout: 480 seconds]
<robclark> leezu: so I went back and checked the sandbox changes needed for newer mesa.. https://chromium.googlesource.com/chromium/src.git/+/d1b3fa1258e2e764c5ff53693d39e5ef64c0a95a%5E%21/ .. maybe --gpu-sandbox-start-early helps with that message about threads already started?
<robclark> (otoh maybe doesn't matter with gpu sandbox disabled?)
<leezu> robclark: Thank you. I just tried, but that leads to "ERROR:elf_dynamic_array_reader.h(64)] tag not found" and "zsh: trace trap chromium --gpu-sandbox-start-early" There is actually a Debian bug report about the thread related Error: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918433 but the workaround suggested there (export MESA_GLSL_CACHE_DISABLE=true) doesn't work
<leezu> either
<leezu> According to the bugreport, the consequence of the error is that the gpu sandbox is disabled
<robclark> hmm, yeah, I'd have thought everything should just work with sandbox disabled..
<leezu> Well, even when I pass --disable-gpu-sandbox, InitializeSandbox is called and the error is printed
<leezu> Would the core / backtrace for the --gpu-sandbox-start-early interest you?
<robclark> huh
<robclark> if you have the call stack easily, I could take a peek.. but defn not a browser expert, other than hitting the sandbox code with a hammer a few times when mesa started spawning threads early
<leezu> [22746:22746:0801/170843.959172:FATAL:gpu_data_manager_impl_private.cc(407)] GPU process isn't usable. Goodbye.
<leezu> Thread 1 "chromium" received signal SIGTRAP, Trace/breakpoint trap.
<robclark> leezu: for a datapoint, fedora f36 has R100 which appears to just work
<leezu> robclark: I just installed debug symbols and the backtrace is at https://pastebin.com/xtgTYbaU
<robclark> bamse: that looks like a reasonable thing for -fixes
<leezu> Keep in mind this is Chromium 97. I will also try with 103
<robclark> not sure if there is an easy way to try different version on fedora.. but I haven't run into problems before so probably at one point in past I was using 97
<robclark> oh, looks like fedora has an update to 103.. I'll install that
<leezu> The backtrace with 103 seems to be the same https://pastebin.com/FV5HnHMc
<robclark> leezu: 103 works on fedora
<robclark> one thought.. do you have VGEM enabled? If so, does disabling it help? Maybe chromium is getting confused by the extra drm device node?
<robclark> (fwiw, I was testing with x11.. I guess I could try gnome-shell wayland session)
<robclark> leezu: hmm, ok.. with wayland it seems to fail in a similar (?) way.. https://paste.centos.org/view/raw/c6bad58c
<leezu> Yes, that's the same issue I have with Ozone Wayland from 98+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016438
<leezu> Given you can repro this on Fedora, do you think it's an upstream bug instead of packaging issue?
<robclark> according to LIBGL_DEBUG=1 it is managing to open the drm device.. so not a sandbox issue
<robclark> yeah, I guess it is an upstream bug
<robclark> it is even managing to create a context
<leezu> Do you have time to open an upstream bug and possibly get attention by the right people?
<robclark> leezu: can you pen a bug?
<robclark> fwiw, enabling flag #ignore-gpu-blocklist gets me hw webgl
<robclark> so I suspect this is just "its not a pci device" lolz
<robclark> I think it is probably still falling back to cpu page rendering (ie. using cpu to put output of webgl onto the page)
<leezu> Nice! Yes, I'm also able to launch 103 with Ozone Wayland platform by passing --ignore-gpu-blocklist
<leezu> I got a backtrace for the GPU detection crash on Firefox (which disables hardware accel).
<leezu> #5 0x000000797baac108 in pci_init () at /usr/lib/aarch64-linux-gnu/libpci.so.3
<leezu> #6 0x000000798064807c in get_pci_status () at ./toolkit/xre/glxtest.cpp:326
<leezu> #7 childgltest() () at ./toolkit/xre/glxtest.cpp:1147
<robclark> hmm, probably not great that libpci crashes.. maybe lspci would repro same issue
<robclark> but I guess similar class of problem.. sw confused that gpu isn't a pci device
<leezu> lspci doesn't crash. It just shows pcilib: Cannot open /proc/bus/pci
<leezu> lspci: Cannot find any working access method.
<robclark> oh, I guess if you are on sc7180, it doesn't even have pci ;-)
falk689 has quit [Remote host closed the connection]
<leezu> I'll suggest the firefox devs to check for pci existence before doing further probing with libpci. Or do you recommend a different approach?
falk689 has joined #aarch64-laptops
<robclark> possibly.. although maybe this crash is the fault of libpci?
<robclark> fwiw, on fedora w/ wayland session, ffox doesn't crash, but "No GPUs detected via PCI"
<leezu> Do you also see "[GFX1-]: glxtest: process failed (received signal 11)"? That refers to the background process crash which checks for GPUs and due to this crash all hardware acceleration is disabled
<robclark> hmm, yeah
<robclark> leezu: filed https://bugzilla.redhat.com/show_bug.cgi?id=2113024 for ffox issue.. I guess probably an upstream issue but I think rh still has ffox devs
<clover[m]> Leo Shen: PR for steev's 5.19 release https://github.com/szclsya/x13s-alarm/pull/1
<leezu> robclark: firefox devs just notified me there's already a bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1696691
<robclark> hmm, that issue seems to be collecting dust
FizzBuzz has joined #aarch64-laptops
<leezu> Yes. I'm not familiar with ffox codebase, but checking if /proc/bus/pci is inaccessible and if so avoiding libpci sounds like an easy fix..
<steev> clover[m]: looks good (if you want you can test out the LRU gen stuff, i'm testing it here at least
<steev> it's what robclark was talking about last night, at least, v13 of it, there will likely be more
<szclsya[m]> clover: looks good, will merge when I have access to my machine
<clover[m]> Nice
<clover[m]> <steev> "clover: looks good (if you..." <- Is that the chromium gpu stuff?
<steev> it's not gpu related, it's memory related
<clover[m]> Looks like valuable patchset for a desktop experience
<clover[m]> Based on testimony
<hexdump0815> steev: i'm using mglru for some months now and this stuff is really nice and works very stable for me
<steev> true, but it's not strictly arm64 laptop related, and so sometimes i feel weird pulling in stuff i want to test and pushing it out to others
<hexdump0815> i was in contact with the author and it is in chromeos kernels from v4.14 on, but the patches for mainline are a newer and improved version
<steev> si :)
<hexdump0815> steev: what is actually the current state of mainline on the c630 - what is still missing to be working? suspend/resume i guess? does s2idle work? wifi is unstable iirc and sound you just got working?
<hexdump0815> camera, lte and fingerprint reader are not working - or?
<hexdump0815> oh - one more q: is it running hot and throttling when under full load or not?
<steev> camera works fine, lte works fine, s2idle works fine
<steev> wifi has been stable for quite a few kernel releases
<hexdump0815> oh - so kind of fully supported then :) ... how long will it survive in s2idle with full battery approx?
<steev> still out of kernel is battery driver (technically i guess the EC driver)
<hexdump0815> what about kdb backlight?
<steev> that's kind of hard to say at the moment - the other day i left it mostly idle but *not* in s2idle, and it was > 1 day of uptime, i'd hope we'd get more than that in s2idle
<steev> kbd backlight isn't controlled in sysfs i don't think, but fn+spacebar works fine to flip through the 3 settings for it
<steev> that reminds, i need to poke at 5.19 for the radxa zero
<steev> i'm not gonna ask the author to backport all the way to 5.10
<steev> and no, fingerprint reader doesn't work (afaik - i don't do biometrics regardless so i wouldn't be testing it here)
<steev> fwiw
<steev> this isn't fully compliant or working but i yanked the 3 patches out
<steev> it's basically the "battery" driver that is still external, yanked out of the patches and put into a dkms-able install
<steev> but i don't have it linking properly, i don't think
<steev> oh, i think the mic, might not work
<clover[m]> Steev do you work with Armbian much?
<steev> clover[m]: negative
<steev> i hang out in their irc channel, and on their discord server, and chat with them
<steev> leezu: robclark: on my c630, passing --ignore-gpu-blocklist doesn't seem to be enough here with 103
FizzBuzz has quit [Quit: Leaving]
<steev> hexdump0815: oh! one other (minor?) issue is that the right speaker appears to be much quieter than the left... but fuck me trying to go through alsa-mixer's controls to figure out what is what
<hexdump0815> steev: thanks a lot for all the c630 info ... and yes: alsa/ucm is a pain :)
<steev> hexdump0815: fwiw, there's a guy who has a massive writeup of everything on github (bm16ton or something) - he emails me, i keep telling him to join the irc channel, he keeps putting all of us on a pedelstal :(
<steev> hm, you know, tmo did send me a new sim card for the galaxybook2, i wonder if i can pop it into the c630 instead...
<steev> UPDATE: And on top of all that despite the extreme gap between our intelligence and skill he still gives me a hand. (lmao... he thinks i'm smart)
<clover[m]> I also saw that you are Gandalf
<clover[m]> How difficult is it to write a driver for usb-c DP
<steev> no no
<steev> bjorn (bamse) is the gandalf... i'm more like smegol... once upon a time i had skills, but now.... i just wants my precious
<steev> i'll be honest here, a) i have absolutely NO idea how difficult it is and b) i spent far too much time working for a company that did content filtering and even though it was like 15 years ago, it still takes me a bit to remember that DP means display port and not.... other things
<steev> one bad thing about having suspend working on the thinkpad.... now i show 19 hours of uptime so i have no idea how much battery i have left
<szclsya[m]> x13s repo has been updated for 5.19.0
<clover[m]> great!!
<leezu> robclark: Fix for ffox https://phabricator.services.mozilla.com/D153401 not yet clear if this will be in for 104 or only 105 release
<robclark> \o/
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
Erisa45 has joined #aarch64-laptops
_kbingham has joined #aarch64-laptops
macc24_ has joined #aarch64-laptops
calebccff_ has joined #aarch64-laptops
suihkulo1ki has joined #aarch64-laptops
jonasbits_ has joined #aarch64-laptops
jonasbits has quit [charon.oftc.net coulomb.oftc.net]
alpernebbi has quit [charon.oftc.net coulomb.oftc.net]
macc24 has quit [charon.oftc.net coulomb.oftc.net]
harvests[m] has quit [charon.oftc.net coulomb.oftc.net]
jelly has quit [charon.oftc.net coulomb.oftc.net]
Erisa4 has quit [charon.oftc.net coulomb.oftc.net]
Erisa45 is now known as Erisa4
javierm has quit [Ping timeout: 480 seconds]
abelvesa has quit [Ping timeout: 481 seconds]
xnox has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
jelly-hme has joined #aarch64-laptops
<steev> gwolf: ^^
<steev> also, we get it, you use arch
<steev> seriously though, that's awesome! \o/
<bamse> i typically do my displaytest using nyancat(1)...but it's not very descriptive to what i'm running it on
<robclark> nice
<steev> i could tell immediately just because the c630 looks... different from the others
harvestz[m] has joined #aarch64-laptops
<bamse> still trying to figure out why the link training fails on the x13s...so while waiting for some documentation i took a detour onto the yoga, just to test my dp patches
jelly-hme has quit []
HdkR has joined #aarch64-laptops
HdkR has quit [reticulum.oftc.net coulomb.oftc.net]
HdkR has joined #aarch64-laptops
HdkR has quit [reticulum.oftc.net coulomb.oftc.net]
abelvesa has joined #aarch64-laptops
HdkR has joined #aarch64-laptops
javierm has joined #aarch64-laptops
jelly has joined #aarch64-laptops
<harvestz[m]> idk I love the thinkpad chassis
<harvestz[m]> what browser is everyone using on the x13s for linux? I'm getting an error for some sites in firefox
clover[m] has joined #aarch64-laptops