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)
Solo has joined #aarch64-laptops
Solo has quit []
derzahl has quit [Ping timeout: 480 seconds]
<steev>
bamse: mani_s: just had a weird one, the x13s was just sitting there plugged in with display blanked and it just... wouldn't wake up at all. there is sadly, nothing in the logs, and oddly, journalctl says there is no previous boot
<bamse>
steev: did it decide to suspend?
<steev>
gnome claims automatic suspend is off
<steev>
but maybe it did anyway?
<bamse>
well, if it did...then that would explain it...if not, we have something else to hunt down ;)
derzahl has joined #aarch64-laptops
<bamse>
but after disabling suspend (in systemd-logind in my case) i've not had any cases of my device dying on me unexpectedly...and i'm as usual lazy when it comes to updating the kernel on my daily driver...so i have 12 days uptime now
<steev>
oh, hm
<steev>
let me make sure systemd doesn't do it under me
<bamse>
i'm pretty sure gnome takes over that ownership
<steev>
i think masking the targets will also stop it even if it's enabled in gnome
<steev>
hm
<steev>
i... am an idiot who had it plugged in to the wrong usb c cable and it was not, in fact, charging the battery
derzahlah has joined #aarch64-laptops
<steev>
bamse: do we get access to the lid LED like they do in the x86 world?
<steev>
i know we don't have ec access, but i'm curious if they wired it up there, or elsewhere
<bamse>
the LED is wired to the EC
<steev>
ah cool, so eventually we will :D
derzahl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
tomf has quit [Read error: Connection reset by peer]
tomf has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
matthias_bgg has quit []
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit []
<steev>
mani_s: something to keep in mind with the work - in your kernel tree you have the x13s's dtb as sc8280xp-thinkpad but in next, where it has been accepted upstream, it's sc8280xp-lenovo-thinkpad-x13s
<steev>
with the iso work*
<mani_s>
steev, my tree is still wip
<mani_s>
i'll update it very soon
<steev>
:)
<steev>
it was just something i noticed because of the missing backlight node
<robclark>
a bit less going on there.. but what I was seeing in video was at least block based
<HdkR>
Quite difficult to snag an image of it
<HdkR>
oh, is FD_MESA_DEBUG only GL?
<HdkR>
Running this through Turnip
<HdkR>
lemme switch it over to TU_DEBUG
<robclark>
yeah, TU_DEBUG=noubwc in that case
<HdkR>
Fancy, still there. Time to try some of the other debug options then
<robclark>
yeah.. and probably ask on #freedreno .. bonus points if you have a trace
<HdkR>
I should probably join that channel at some point
<HdkR>
Oh.
<HdkR>
It goes away if I turn on vsync.
<HdkR>
VK_PRESENT_MODE_IMMEDIATE_KHR quirk
<HdkR>
That's pretty nasty
djakov has joined #aarch64-laptops
derzahlah has quit [Remote host closed the connection]
<robclark>
so.. not sure exactly what that turns into as far as wsi.. but frontbuffer scannout doesn't _really_ work w/ UBWC (since GPU can't automically write both meta + pixel at same time).. same is true of really any bw compressed format.. we have a usage flag in minigbm for that (ie. for things like low-latency ink/stylus)
<HdkR>
Driver bug to even allow UWBC on the frontbuffer then? :)
<HdkR>
Also TU_DEBUG=noubwc doesn't work through WSI, which is why the problem still stayed there?
<robclark>
ubwc is kinda wsi dependent.. and depends on who allocates the buffers.. if driver is told to import ubwc and render to it, it kinda has to ignore noubwc
<robclark>
there probably should be a PIPE_BIND_SCANOUT_FRONTBUFFER type thing for cases where the driver is the one allocating the frontbuffer (and I suppose some sort of vk equiv)..
jhovold has quit [Ping timeout: 480 seconds]
<HdkR>
Opened an issue to track it so it won't get lost. Tons of Windows games don't enable vsync by default
<robclark>
it isn't _really_ a driver bug, as the driver doesn't have this information.. I think x11 isn't clever enough to use ubwc so maybe things are ok there (?).. unsure about what wayland does
<HdkR>
Oh, I'm using i3 so no idea what Wayland would do
<robclark>
cat /sys/kernel/debug/dri/0/state and see if modifier is something non-zero
<HdkR>
modifier=0x500'0000'0000'0001
<robclark>
yup, that is QCOM_COMPRESSED (ie. UBWC)
<robclark>
gbm probably needs to grow a GBM_BO_USE_FRONT_RENDERING flag like we added to minigbm
<HdkR>
Sounds fancy
<robclark>
It's a lot more noticeable when you are doing actual frontbuffer rendering tricks to get rid of stylus-tip to pixel latency, vs what is (probably) just a blit in this case
<robclark>
HdkR: try starting Xorg with FD_MESA_DEBUG=noubwc