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)
hexdump01 has joined #aarch64-laptops
zjstraus has quit [Ping timeout: 480 seconds]
zjstraus has joined #aarch64-laptops
zjstraus2 has joined #aarch64-laptops
zjstraus has quit [Ping timeout: 480 seconds]
zjstraus2 is now known as zjstraus
<quinine> <clover[m]> "i think i am happy with vivaldi...." <- I'll stick with Firefox. Apart from political reasons, but also because chromium-like wayland support has been poor.
<clover[m]> i use firefox too. the container tabs are super useful for my work
<quinine> container is a killer feature :D
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
rfs613- has joined #aarch64-laptops
rfs613 has quit [Ping timeout: 480 seconds]
systwi has quit [Read error: Connection reset by peer]
systwi has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
Caterpillar has quit [Remote host closed the connection]
Caterpillar has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
_xav_ has quit [Ping timeout: 480 seconds]
_xav_ has joined #aarch64-laptops
init_x13s has joined #aarch64-laptops
rfs613- is now known as rfs613
<bryanodonoghue> I see a lag when moving the mouse from one screen to another on x13 exeat
<bryanodonoghue> Might be worth running through a perfetto test
hightower2 has joined #aarch64-laptops
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
<jhovold> exeat, bryanodonoghue: not seeing any lag when moving the mouse pointer between screens here with full-hd external display, Xorg, mesa-23.1.0-rc4 and my latest 6.3.1 wip branch
<bryanodonoghue> I'm on a similar kernel but not the same mesa
<bryanodonoghue> I'll try an upgrade
<jhovold> didn't you say you were runnings steev's branch?
<jhovold> bryanodonoghue, exeat: steev has quite a few display related patches on top of my branch, so may be worth trying without those
<clover[m]> no lag here with 2K external displays, Mesa 23.0.3, and steev's 6.3.1
<init_x13s> quick comment about mesa, ive been running 23.1.0-rcx since rc2 without any specific patches and it seems to work flawlessly (for desktop use). it's worth giving it a try.
rmsilva has quit [Quit: WeeChat 3.8]
rmsilva has joined #aarch64-laptops
<exeat> bryanodonoghue: did you also get a similar stacktrace in dmesg?
<exeat> jhovold: thanks, I'll try with your wip/sc8280xp-v6.3.1 branch and report back if I can reproduce it (though it's pretty rare)
<clover[m]> BIOS Update for x13s available.... (full message at <>)
derzahl has joined #aarch64-laptops
<steev> Supported the warnning message support during firmware updates.
<steev> wat
<init_x13s> haha
<steev> i think it means they'll show a warning message when the firmware is updating
<steev> because the c630 does
<steev> the thinkpad never has
<init_x13s> I wonder what the battery firmware updates does
<clover[m]> better battery life i hope
<init_x13s> I would have preferd the "battery stops draining if you don't shut down laptop by holding power more than 10 sec" -answer
<init_x13s> haha
hightower2 has quit [Ping timeout: 480 seconds]
<steev> re mesa: the only outstanding patches that i'm still showing are the 4 from robclark, and i'm not sure what the status of those is yet
<init_x13s> are they really related to freedreno?
<init_x13s> i don't see much difference between 23.1.0-rcx and 23.0.0 with the patch stack.
<init_x13s> but my use case is limited to desktop use.
<steev> they are for syncobj deadline, i don't quite fully understand it. just that rob mentioned that they were needed in his patchset
<steev> when it comes to gpu stuff, i definitely defer to people who know better than me (which is pretty much anyone)
<clover[m]> Anyone know why this is happening with my archiso? Built with latest kernel and getting this efivars error and a probe deferral
<steev> looks like a missing dependency isn't bringing up usb and you're deferring
<steev> make sure what you have loaded on a system is in the initramfs for your archiso?
<init_x13s> steev: totally agree on what you said about gpu. but since these patchs aren't in the 23.0.0 patchset I have been using, i just like to keep myself updated, with all the problems that comes with this strategy
<steev> I generally like to carry as few external patches as possible, and it could be that the syncobj stuff is/was waiting on it being in a kernel
<robclark> steev: you don't need those patches, that is something completely unrelated that I'm working on
<init_x13s> thx for the clarification robclark
<robclark> fwiw that mesa MR is related to pending syncobj kernel patch.. but defn not needed
<steev> right, i have the syncobj patchset in mine
<steev> can definitely drop it though
hightower2 has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
<init_x13s> there's also mention of "memory training" update.
<clover[m]> Maybe something to do with s3 sleep?
<konradybcio> clover: what if you try setting CONFIG_PHY_QCOM_QMP=y instead of =m?
init_x13s has quit [Remote host closed the connection]
<steev> the numbers look about the same, i think
<steev> memwise
<konradybcio> @steev it's probably about stability, a bios update is not gonna your memory faster
<HdkR> Well, until your desktop BIOS forgets to support XMP/EOCP, but that's a different issue :P
<steev> konradybcio: well, at least it didn't make it slower :)
iivanov has quit [Ping timeout: 480 seconds]
<clover[m]> <konradybcio> "clover: what if you try setting..." <- What does this do? I found out I stop getting that issue when I explicitly call the dtb in kernel command line. Even with Linux mode enabled in bios
<clover[m]> This is only for the rescue image btw.
<clover[m]> Always giving me problems
<clover[m]> Probably sunk 100 hours into it idk
<steev> that builds the qcom qmp phy into the kernel, instead of it being a module
<clover[m]> i have these in my mkinitcpio.conf:... (full message at <>)
<clover[m]> It seems like every time systemd or journald is involved, squashfs complains about data corruption 🤔