14:00 <jhovold> Here's an updated wip branch for the X13s:

14:00 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.16-rc2

14:00 <jhovold> Changes include:

14:01 <jhovold> - fix dp hotplug wlroots/xorg crashes (6.16-rc1 regression)

14:01 <jhovold> - fix ath11k stats query (timeout, cpu usage)

14:01 <jhovold> Known issues:

14:01 <jhovold> - interconnect icc_bw_lock lockdep splat (6.16-rc1 regression)

14:01 <jhovold> - microphones broken with alsa-ucm-conf 1.2.14 (revert to 1.2.13)

14:01 <jhovold> Here's an updated wip branch for the T14s and X Elite:

14:01 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.16-rc2

14:01 <jhovold> Changes include:

14:01 <jhovold> - fix dp hotplug wlroots/xorg crashes (6.16-rc1 regression)

14:01 <jhovold> - fix ath11k stats query (timeout, cpu usage)

14:01 <jhovold> Known issues:

14:01 <jhovold> - eusb2 phy module has been renamed (e.g. Kconfig and initramfs)

14:07 <binarycraft[m]> I could also make a PR

14:53 <steev> https://patchwork.kernel.org/project/linux-arm-msm/patch/20250602081638.51724-1-elliot.huang.signed@gmail.com/ is the patchwork link, for those not expecting a matrix message to spit out a patch file download

15:45 <jhovold> binarycraft[m]: I basically only include patches that I've reviewed and tested myself (on the t14s or reference design), with some expections for critical and/or obvisouly correct patches for other x1e devices

15:47 <jhovold> and since audio support is in the state it is, and with speaker protection missing, I won't be enabling audio for any machine before it's mainline

15:48 <binarycraft[m]> That make sense, thanks

18:10 <zdykstra> I haven't followed for the last couple of weeks - I saw / thought I saw that 4 lane DP was working on the x13s (which presumably enables 4k@60hz) - did I see that correctly / where does that stand now?

18:47 <JensGlathe[m]> It's working great. all ports (except with my type-c display, only one) , all orientations. In my tree and packages since 6.15.0-jg-5

18:52 <JensGlathe[m]> Actually it was 2-ish implementations. One from alexVinarskis where the x1e80100 part is still left in, and one from Neill Armstrong / konradybcio which is the qmpphy-combo core now.

19:03 <konradybcio> Jens Glathe: do you get a link training error, or what happens?

19:06 <JensGlathe[m]> one the USB Port 0, I get odd behaviour. Hot-plug gives only data, but also no link training error. Booting with it plugged in I get the desired screen (4 lanes), either orientation. unplugging freezes the GUI.

19:07 <JensGlathe[m]> USB1 works normally in all situations.

19:07 <konradybcio> is there a way you can grab xbl log?

19:09 <JensGlathe[m]> I guess I could at least try. Do I need patches for this?

19:09 <konradybcio> this is more of a "do you have a serial console"

19:09 <JensGlathe[m]> on the x13s - no, sorry

19:10 <konradybcio> oh i was under the impression you had issues with the angrybox

19:11 <JensGlathe[m]> that was x13s specific. angrybox is capricious but works fine after replug at the latest, all ports, all orientations. HP X14 also works all ports, all orientations.

19:11 <konradybcio> hm, i think my x13s had no such complaints

19:12 <JensGlathe[m]> and it is limited to that one display. Use hdmi adapter, no such issues.

19:12 <JensGlathe[m]> tb16 works one orientation, both ports (need to investigate)

19:13 <JensGlathe[m]> wdk2023 works all ports, all orientations after correcting an enable gpio

19:15 <JensGlathe[m]> steev and steveej helped debug / verify this

19:15 <JensGlathe[m]> the x13s usb0 issue

19:16 <konradybcio> are you on latest bios?

19:16 <JensGlathe[m]> 1.64, yes

19:16 <konradybcio> and i'm assuming it's not any special unit

19:16 <JensGlathe[m]> 1.63 had this too on mine

19:16 <JensGlathe[m]> 21BC001GE

19:16 <JensGlathe[m]> 21BX*

19:25 <steev> which adapter

19:25 <steev> or monitor

19:25 <JensGlathe[m]> Iiyama 27" type-c with integrated hub, XUB2792QSN

19:26 <JensGlathe[m]> all of my adapters work, 2 lane or 4 lane

21:56 <kuruczgy[m]> anthony25: yep, `WLR_RENDER_NO_EXPLICIT_SYNC=1` seems to fix the flickering on sway. (Will keep observing, the issue is kind of intermittent so still not 100% sure this fixed it...)

21:56 <kuruczgy[m]> Any idea for how to begin hunting down this bug?

21:57 <anthony25> do you have the problem in gnome?

21:57 <kuruczgy[m]> (Also tagging robclark, if you missed it I have this issue on kernel 6.16-rc1, mesa 25.1.3, sway 1.11, so pretty much everything the latest.)

21:58 <anthony25> just in gnome I don't remember if it was easy to tell if explicit sync was used or not

21:58 <kuruczgy[m]> Does GNOME have explicit sync enabled by default? How do I check that?

21:59 <anthony25> otherwise in hyprland it was easy to tell, it's enabled by default, and running a gtk app for example was super flickery when it wasn't respecting what the driver was exposing

22:00 <kuruczgy[m]> But in hyprland it was a hyprland bug, right? So it should be fixed on the latest hyprland

22:01 <anthony25> it was because hyprland was using explicit sync when msm disabled it, yes

22:01 <anthony25> and yes it's fixed

22:02 <robclark> the only thing I've seen vaguely familiar (I use gnome-shell daily, but test hyprland occasionally) is something with timeline semaphores seems to get into a bad shape if I get a lot of gpu hangs (like if I'm testing some buggy mesa change).. restarting g-s "fixes" it so I think somehow the issue is on g-s side, but haven't really had time to debug it more than that

22:02 <anthony25> but I just mean that in hyprland, it's easy to tell if explicit sync is buggy, and also easy to check if explicit sync is enabled or not

22:05 <anthony25> kuruczgy[m]: I can check in Tumbleweed once sway 1.11 makes it in the repo

22:05 <kuruczgy[m]> I can try a few compositors (GNOME, hyprland) tomorrow to gather some data

22:05 <kuruczgy[m]> robclark Is there some way to gather more info/logs when I can reproduce the bug?

22:07 <robclark> try other compositors.. and also check dmesg to see if it is following gpu crashes I guess

22:08 <kuruczgy[m]> But this kinda sounds like this will take more than a couple days to track down, for now I will set `WLR_RENDER_NO_EXPLICIT_SYNC=1` in my nixos config.

22:08 <kuruczgy[m]> It seems that explicit sync just got enabled in wlroots in the latest release, so it makes sense that there could still be some rough edges.

22:09 <kuruczgy[m]> robclark: no gpu crash in dmesg at all

22:09 <robclark> hmm, ok.. well I guess that rules out on theory

22:24 <kuruczgy[m]> robclark: anthony25: found this sway issue, quite a few people complaining of flickering after the latest update (with `WLR_RENDER_NO_EXPLICIT_SYNC=1` being the workaround), with various graphics drivers, so probably a sway/wlroots bug and not a driver issue: https://github.com/swaywm/sway/issues/8755

22:26 <robclark> hmm, ok.. I guess testing a few other compositors could confirm that, but hopefully it is not-my-bug(TM) :-P

22:27 <anthony25> that's kind of good news, at least it should be easy to replicate!

22:28 <robclark> fwiw, I think electron + chrome/ium apps do test to trigger these sorts of issues easier because they use partial-swap (so they don't redraw the full frame each time, but just the part that has change.. which if it gets out of sync goes all flickery)

22:29 <anthony25> makes sense

22:30 <anthony25> when explicit sync was broken in hyperland, foot (terminal) also flickered due to the damage tracking, and gtk menus were flickering a lot

22:36 <valpackett> robclark: firefox does that too (guess who hooked that up for egl/linux :D)

22:37 <robclark> ahh, nice

22:38 <anthony25> valpackett: it doesn't need webrender compositor enabled for that?

22:38 <valpackett> nope

22:38 <anthony25> oh cool!

22:39 <valpackett> for more testing you can increase gfx.webrender.max-partial-present-rects which by default is 1 (merging all the damage rects into an overall bounding box)