10:04 tzimmermann: jfalempe, i'll give the clients series another day on the list and merge it tomorrow morning. is that ok for you?
11:17 emersion: MrCooper: i'm so sorry that i bugged you about the dmabuf import stuff and still didn't find the chance to get back to you. i'll try to do this soon. thanks for sending the reply on the ML!
11:19 MrCooper: no worries
11:34 pinchartl: tzimmermann: mlankhorst: could someone merge https://lore.kernel.org/all/87frob3neo.wl-kuninori.morimoto.gx@renesas.com/ ?
11:37 tzimmermann: pinchartl, hi. ok. is that patch an immediate fix for upstream?
11:38 tzimmermann: pinchartl, or do you want all 3 patches?
11:39 pinchartl: it's not a fix, it's for v6.14
11:40 pinchartl: or can it be pushed to drm-misc by anyone, without disturbing you ?
11:41 javierm: pinchartl: it can be pushed directly to drm-misc https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html#merge-criteria
11:42 pinchartl: ok
11:42 pinchartl: tomba: could I volunteer you one more time ? :-)
11:44 tomba: pinchartl: you have a very crooked definition for "voluteer"... =)
11:45 javierm: more like voluntold? :D
11:47 pinchartl: let's see
11:47 pinchartl: https://en.wiktionary.org/wiki/volunteer
11:47 pinchartl: "(transitive, informal) To offer the services of (someone else) to do something."
11:47 pinchartl: there we go :)
11:47 tomba: pinchartl: looks like I wasn't included in the v6. but yes, I'll have a look and push if it's fine.
11:48 tomba: pinchartl: I see. I stand corrected =)
11:49 pinchartl: we could also try definition 5 ("(intransitive, botany) To grow without human sowing or intentional cultivation.") but that's probably even more of a stretch :-)
11:50 javierm: haha
11:51 pinchartl: I could imagine bugs volunteering that way. fixes, less so
11:54 javierm: pinchartl: it reminds me about this blog post https://dangoslen.me/blog/writing-software-is-like-growing-a-garden/
12:03 tzimmermann: oh, it's a single patch. i'll merge it in a bit
12:04 pinchartl: javierm: I wonder what the equivalent in software development of sustainable gardening would be, when you let some weeds grow and some bugs feed on your plants to achieve a better overall balance
12:05 pinchartl: tzimmermann:
12:05 pinchartl: thanks
12:05 pinchartl: tomba: ^^
12:05 tomba: ok, thanks!
12:10 pq: pinchartl, isn't that just another way of saying perfect is the enemy of good?
12:12 pinchartl: pq: is that a good enough excuse to introduce bugs ? :-)
12:15 pq: up to project policy :-p
12:20 ccr: PINE
12:21 ccr: ehh .. oops.
12:22 tzimmermann: pinchartl, tomba, merged
12:26 pinchartl: tzimmermann: thanks a lot
18:29 dviola: hello everyone, I've been experiencing an issue that I believe is related to this issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8730 -- exactly the same issue, with recent kernels (6.11.6-arch1-1) on archlinux, upon investigation it turns out that kernel 6.6.60 works, but 6.6 doesn't nor does master
18:31 dviola: I've been talking on #wayland about this and it's been pretty confusing, I ended up bisecting it which points to this: https://0x0.st/Xkb5.txt -- but that makes things more confusing because it doesn't seem a regression?
18:32 dviola: and the bug report points to this patchset: https://lore.kernel.org/dri-devel/20230719014218.1700057-1-zack@kde.org/ and most of those commits are already upstreamed
18:34 dviola: in my case, the cursor is upside down just like in that bug report, hapepns only in the QEMU VM with most wayland compositors (sway, weston, hyprland, etc)
18:36 dviola: WLR_NO_HARDWARE_CURSORS=1 is a workaround to get it to work but it was working fine without that for a while, I am hoping that someone more experienced could offer some help to figure out where the regression actually is because it doesn't make sense
18:40 dviola: in this case the bisect was done in reverse order, so https://0x0.st/Xkb5.txt is the commit that "fixes" the issue but that code is stlil intact on master, so it should work?
18:42 dviola: still*
18:43 soreau: dviola: typically after a bisect, I try the identified commit and the commit before it, to make sure the bisect is correct
18:48 dviola: right
18:52 dviola: I still need to do that, full bisect log: https://0x0.st/Xkb7.txt
18:54 dviola: master should in theory work since it has all the patches from that patchset
19:28 dviola: when discussing this on #wayland, MrCooper mentioned ("not a kernel regression / not 100% reproducible") which I think is right, it was working with 6.11.x and for some reason isn't anymore
19:48 dviola: I still want to get to the bottom of it but it's beginning to look like I might be chasing a heisenbug or similar
20:04 benjaminl: the convention is to drop Reviewed-by trailers after making significant changes as part of a later review, right?
20:06 airlied: benjaminl: usually, sometimes see v1-R-b style
20:56 dliviu: hello, can I push https://patchwork.freedesktop.org/patch/msgid/20241111134720.780403-1-akash.goel@arm.com into drm-misc-fixes, hopefully makes it into v6.12 before it's too late?
23:56 RAOF: Ok, what am I misunderstanding? I have a (set of) dma-buf submitted from a client. I import it (them) using gbm_bo_import(... USE_SCANOUT ...). I grab the gem handles from the gbm_bo. I create a KMS FB from them with AddFB2WithModifiers. I create an atomic update setting the primary plane to that FB ID. I AtomicCommit the update. I get a _momentarily corrupted_ display update (maybe 1 vrefresh cycle) that resolves without me submitting any more updates.
23:59 RAOF: This is clearly something _I'm_ doing wrong, because it occurs on both i915 and amdgpu. The corruption looks a bit like a synchronisation artifact - on (oldish) i915 it looks like a band of the previous frame is included, on amdgpu there's a band (in approximately the same place?!) with what looks like compression plane artifacts (lime green squares on the edges of the rendered gears).