02:12 <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.

02:13 <clover[m]> i use firefox too. the container tabs are super useful for my work

02:14 <quinine> container is a killer feature :D

13:14 <bryanodonoghue> I see a lag when moving the mouse from one screen to another on x13 exeat

13:14 <bryanodonoghue> Might be worth running through a perfetto test

14:29 <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

14:30 <bryanodonoghue> I'm on a similar kernel but not the same mesa

14:31 <bryanodonoghue> I'll try an upgrade

14:31 <jhovold> didn't you say you were runnings steev's branch?

14:34 <jhovold> bryanodonoghue, exeat: steev has quite a few display related patches on top of my branch, so may be worth trying without those

14:35 <clover[m]> no lag here with 2K external displays, Mesa 23.0.3, and steev's 6.3.1

14:38 <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.

15:41 <exeat> bryanodonoghue: did you also get a similar stacktrace in dmesg?

15:42 <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)

16:47 <clover[m]> BIOS Update for x13s available.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/oADzlMhzajUUHhILzgIMdmjM>)

16:52 <steev> Supported the warnning message support during firmware updates.

16:52 <steev> wat

16:52 <init_x13s> haha

16:53 <steev> i think it means they'll show a warning message when the firmware is updating

16:53 <steev> because the c630 does

16:53 <steev> the thinkpad never has

16:53 <init_x13s> I wonder what the battery firmware updates does

16:55 <clover[m]> better battery life i hope

16:56 <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

16:56 <init_x13s> haha

17:54 <steev> re mesa: the only outstanding patches that i'm still showing are https://github.com/steev/mesa/commits/main the 4 from robclark, and i'm not sure what the status of those is yet

17:56 <init_x13s> are they really related to freedreno?

17:56 <init_x13s> i don't see much difference between 23.1.0-rcx and 23.0.0 with the patch stack.

17:56 <init_x13s> but my use case is limited to desktop use.

17:57 <steev> they are for syncobj deadline, i don't quite fully understand it. just that rob mentioned that they were needed in his patchset

17:57 <steev> when it comes to gpu stuff, i definitely defer to people who know better than me (which is pretty much anyone)

17:59 <clover[m]> Anyone know why this is happening with my archiso? Built with latest kernel and getting this efivars error and a probe deferral

17:59 <steev> looks like a missing dependency isn't bringing up usb and you're deferring

18:00 <steev> make sure what you have loaded on a system is in the initramfs for your archiso?

18:04 <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

18:05 <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

18:15 <robclark> steev: you don't need those patches, that is something completely unrelated that I'm working on

18:16 <init_x13s> thx for the clarification robclark

18:16 <robclark> fwiw that mesa MR is related to pending syncobj kernel patch.. but defn not needed

18:17 <steev> right, i have the syncobj patchset in mine

18:17 <steev> can definitely drop it though

19:14 <init_x13s> https://download.lenovo.com/pccbbs/mobiles/n3huj13w.txt

19:15 <init_x13s> there's also mention of "memory training" update.

19:35 <clover[m]> Maybe something to do with s3 sleep?

19:42 <konradybcio> clover: what if you try setting CONFIG_PHY_QCOM_QMP=y instead of =m?

20:45 <steev> the numbers look about the same, i think

20:45 <steev> memwise

21:06 <konradybcio> @steev it's probably about stability, a bios update is not gonna your memory faster

21:07 <HdkR> Well, until your desktop BIOS forgets to support XMP/EOCP, but that's a different issue :P

21:29 <steev> konradybcio: well, at least it didn't make it slower :)

21:33 <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

21:33 <clover[m]> This is only for the rescue image btw.

21:33 <clover[m]> Always giving me problems

21:33 <clover[m]> Probably sunk 100 hours into it idk

22:04 <steev> that builds the qcom qmp phy into the kernel, instead of it being a module

22:09 <clover[m]> i have these in my mkinitcpio.conf:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/xvRFjlyLQqDeDDAgAglmZVnm>)

23:12 <clover[m]> It seems like every time systemd or journald is involved, squashfs complains about data corruption 🤔