ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
<Meti[m]>
The speakers also don't work I think
<Meti[m]>
Did I just downlosd the wrong image?
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Quit: Konversation terminated!]
Caterpillar has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
luca020400 has quit [Quit: WeeChat 4.6.3]
luca020400 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<steev>
exeat: we just got .92 in kali and i still can't reproduce it on the X13s :(
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<craftyguy>
has anyone used slbounce on the x13s lately (e.g. woth 6.15 or later)?
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
not on x13s, but on Windows Dev Kit 2023 with newest UEFI. Working fine as ever.
<JensGlathe[m]>
Even have a WoA 11 VM running 😁
<JensGlathe[m]>
Kernel is 6.16.0-rc4-jg-1
chrisl has quit [Ping timeout: 480 seconds]
<craftyguy>
It seems like every time I go to use it my config for it breaks in some weird way. I touched nothing and now booting to el2 with the dtbo just ends with a blank screen right around where udev loads drivers in the initramfs
chrisl has joined #aarch64-laptops
<craftyguy>
Ah kernel log says "CPUs in EL1" sad, that's probably why I lose display and stuff since I'm using the el2 dtbo thing
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Hmm. The 6.16 kernel contains travmurav 's patches for generating -el2 dtbs during build. I use these, set the /etc/flash-kernel/machine accordingly with suffix (EL2) and its installing the right dtb when installing a new kernel.
chrisl has joined #aarch64-laptops
<craftyguy>
Johan's 6.16 kernel includes that?
<craftyguy>
looks like slbounce was removed from my esp somehow. wtf, I don't remember doing that :/
<JensGlathe[m]>
its in the mainline base, yes
<JensGlathe[m]>
sorry upstream
chrisl has quit [Ping timeout: 480 seconds]
<craftyguy>
Re-added slbounce to the esp and it almost boots. nvme controller fails or something
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
if nvme fails it doesn't have the dtbo for el2 - needs to activate the arm-ssmuv3.
<craftyguy>
ya I'm confused, because I am providing it.
<craftyguy>
regenerated it and it's fine now 🤷♂️
<JensGlathe[m]>
More glitches in the matrix
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
ravikant_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JosDehaes[m]>
yeah chromium also completely b0rked for me on the yoga. Interestingly not on asahi (exact same package), so the issue is with the driver?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
krzk has quit [Remote host closed the connection]
krzk has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
ravikant_ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
<icecream95>
Setting MESA_EXTENSION_OVERRIDE=-GL_ARB_map_buffer_range fixes some of the problems with Chromium, so the implementation of the extension may be buggy
<icecream95>
Hmm, with FD_MESA_DEBUG=flush I see a crash during pipe_buffer_map_range, so maybe that is the case: https://0x0.st/8GD8.txt
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
valgrind says there is a use-after-free...
chrisl has joined #aarch64-laptops
<\[m]>
Jos Dehaes didn't you have a m4? thought asahi was just m1 and m2
<JosDehaes[m]>
* from work which has both fedora asahi and asahi -alarm
<JosDehaes[m]>
* from work which has both fedora asahi and asahi-alarm
<\[m]>
did you benchmark building under mac and linux diff?
<JosDehaes[m]>
yes M3/M4 support seems far off still
<JosDehaes[m]>
\[m]: on the M2? Not really. I only use the device for asahi testing
<JosDehaes[m]>
what would you like to know? Compile what?
<\[m]>
just out of interest, nothing specific
chrisl has joined #aarch64-laptops
Guest18205 has quit [Quit: Be right back...]
<JosDehaes[m]>
I have the device sitting next to me, so just ask and I can test 😁
mani_s has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mani_s_ has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
mani_s is now known as Guest21601
mani_s_ is now known as mani_s
mani_s has quit []
mani_s has joined #aarch64-laptops
mani_s_ has joined #aarch64-laptops
mani_s_ has quit []
mani_s is now known as Guest21603
mani_s has joined #aarch64-laptops
mani_s has quit []
Guest21603 has quit []
mani_s has joined #aarch64-laptops
mani_s has quit []
mani_s has joined #aarch64-laptops
mani_s has quit [Quit: Leaving]
mani_s has joined #aarch64-laptops
mani_s has quit []
Guest21601 is now known as identify
identify is now known as mani_s
<icecream95>
I think the map_buffer_range stuff is a red herring... MESA_EXTENSION_OVERRIDE=-GL_ARB_base_instance fixes all of the issues
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
reng has quit [Ping timeout: 480 seconds]
reng has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
I'm fairly certain it's a Chromium bug where having both MapBufferRange and DrawElementsInstancedBaseVertexBaseInstance enabled at the same time was not tested.
chrisl has joined #aarch64-laptops
<icecream95>
It's not Freedreno-specific, since there are issues with Zink as well if *both* of the extensions I listed are disabled
<icecream95>
With them both disabled, Chromium uploads data just before every draw. MapBufferRange just provides a different way to upload it.
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
*BaseVertex* allows uploading one big buffer and making multiple draws from that buffer.
<icecream95>
In the buggy configuration, Chromium uploads two small buffers, but still uses *BaseVertex* to offset the position in the buffer. That causes out-of-bounds buffer reads
chrisl has joined #aarch64-laptops
<icecream95>
The reason why FD_MESA_DEBUG=flush seemed to fix it is because multisample clears crash the GPU process when FD_DBG(FLUSH) set, thus Chromium falled back to not using the extensions
<icecream95>
Not really anything to do to fix it but set MESA_EXTENSION_OVERRIDE=-GL_ARB_base_instance , wait for a Chromium update, and maybe someone should file a bug report
icecream95 has quit [Quit: rcirc on GNU Emacs 29.1]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
JosDehaes[m]: what happens if you `apitrace trace chromium-browser` on asahi and then replay on the yoga?
<robclark>
ahh, interesting icecream95.. I'll look closer at chromium apitrace dump about what it is doing with ARB_base_instance
<robclark>
oddly, I checked w/ CrOS gpu team and they don't seem to have any issues reported w/ beta channel (which is on 138).. but maybe something is different w/ gles vs gl paths
chrisl has joined #aarch64-laptops
SpieringsAE has quit [Quit: SpieringsAE]
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<tobhe[m]>
also just got a report of someone saying chromium update on their x13s produced weird graphical glitches
<robclark>
no idea why steeve isn't seeing issues, I wouldn't expect anything diff btwn a690 and x1-[48]5
<robclark>
`MESA_EXTENSION_OVERRIDE=-GL_ARB_base_instance` does work for me too
craftyguy has quit [Remote host closed the connection]
<robclark>
it's possible that chromium built for gles instead of gl doesn't hit this (but idk if any distro does that).. just a theory because CrOS folks don't seem to be hitting this AFAIU
chrisl has joined #aarch64-laptops
craftyguy has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
tobhe[m]: which Linux distribution was that for the chromium graphical glitches?
<tobhe[m]>
that is Ubuntu with the chromium snap
<janrinze>
Ah, okay..
<janrinze>
On debian trixie all is still well. although i don't update too often due to an extra line i need in grub. (the dtb line which gets removed on kernel updates..)
chrisl has joined #aarch64-laptops
<ukleinek>
janrinze: I would expect that you can tweak the script that generates your grub config to add the dtb line
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
ukleinek: if only i knew how :-D
<ukleinek>
janrinze: If it's Debian it's in /etc/default/grub
<tobhe[m]>
janrinze: actually installing flash-kernel should be enough
<tobhe[m]>
that should install a kernel upgrade hook that copies the dtb to /boot and update grub automatically
chrisl has joined #aarch64-laptops
<janrinze>
tobhe[m]: I actually made a bootable USB stick in case it happens again, from that stick I can manually 'fix' the grub.cfg :-D
<janrinze>
I'll have a look at flash-kernel and see what it does.
<tobhe[m]>
actually Debian might be missing a patch for that to work. let me find the ubuntu one...
<steev>
janrinze: if you are just using debian's kernel, you can get away with just copying the dtb to /boot/efi/ (named as is) - as long as the linux option is enabled in the x13s's bios
ungeskriptet_ has quit [Remote host closed the connection]
<robclark>
JosDehaes[m]: but did you see the corruption or not?
<robclark>
I mean when you replay it
<JosDehaes[m]>
yes, it's completely garbled and unusable
<JosDehaes[m]>
replay?
<JosDehaes[m]>
sorry not familiar with that tool, I haven't ran it on asahi yet
<robclark>
`apitrace replay chromium.trace` on asahi (or visa versa, record on asahi and replay on yoga)
ungeskriptet has joined #aarch64-laptops
<JosDehaes[m]>
ok will try
<robclark>
my expectation is that garbled or not only depends on the driver you capture on, not the driver you replay on (pointing to a chromium bug triggered by combination of extensions the driver exposes or something along those lines)
<JosDehaes[m]>
ls
<JosDehaes[m]>
replaying the trace on asahi indeed shows corruption, but the app immediately closes
<JosDehaes[m]>
so hard to say for sure
<robclark>
add -w to wait on last frame (assuming last frame isn't all black from chrome shutting down)
<robclark>
so chrome is identifying freedreno and doing something buggy?
<JosDehaes[m]>
hmm
<JosDehaes[m]>
somehow apitrace doesn't want to write a trace file on asahi 🤔
<JosDehaes[m]>
indeed with replay -w window completely garbled
<robclark>
yeah, it is something buggy that chrome is doing when GL_RENDERER=="freedreno"
<JosDehaes[m]>
damn spent all day yesterday to build chromium so I could use it on the yoga (to test if that would use the video acceleration - firefox uses ~20% CPU when playing youtube)
<JosDehaes[m]>
and now they foil me again 😂
<robclark>
JosDehaes[m]: the official workaround is to launch chromium like: force_gl_vendor=chromiumlolz chromium-browser
<robclark>
(ie. force_gl_vendor env var)
<JosDehaes[m]>
Thx wil try later
<steev>
robclark: confirming that also fixes the shit with brave
<steev>
well, works around it
<robclark>
\o/
whiskey9 has quit [Ping timeout: 480 seconds]
<steev>
so i guess, maybe trixie/testing mesa doesnt return freedreno?
<steev>
ah, yeah, it used to return qualcomm ?
<steev>
oh no, i was looking at device vendor
<JosDehaes[m]>
confirmed here too
<robclark>
yeah, it has always returned "freedreno"..
<robclark>
steev: could you check chrome://gpu on trixie? Maybe gpu accel isn't working at all?
<robclark>
click "download report to file" and then paste/send it
<robclark>
steev: hmm, extension list is a bit different.. I guess different ANGLE version.. I wonder if we could override it to not use ANGLE on the cmdline
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
Lucanis_ has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<lynxy>
is there a trick to getting codec hardware decoding working in firefox on the snapdragon devices?
chrisl has joined #aarch64-laptops
<steev>
gotta enable it in the config? iirc
<steev>
as well as having the patches and firmware for thee kernel depending on device
<steev>
patches for kernel and firmware*
<HdkR>
Vulkan video decode/encode can't come soon enough :)
<steev>
firmware is in the firmware repo, just gotta get the patches submitted i suppose... and then people can ffigure out why userspace locks up when seeking
<lynxy>
i assume thse patches are included in jhovold's kernel fork?
chrisl has quit [Ping timeout: 480 seconds]
bionade24 has quit []
bionade24 has joined #aarch64-laptops
<lynxy>
aand my windows partition has killed itself, nice
<lynxy>
it really has to be an only child or it just dies
chrisl has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
bull has joined #aarch64-laptops
bull has quit [Quit: Leaving]
icecream95 has quit [Quit: rcirc on GNU Emacs 29.1]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
so patching this in to /usr/share/drirc.d/00-mesa-defaults.conf is a way to get chromium working again without setting env vars:
<robclark>
but someone should probably file a bug upstream.. (idk if the root issue is chromium or ANGLE.. but _something_ is matching on the vendor name and then screwing things up)