09:45 mlankhorst: lumag: for some reason people keep committing patches to drm-misc-next-fixes.. don't know why
09:46 mlankhorst: sima, airlied: Can I just cherry pick that patch to drm-misc-fixes and reset to rc1?
09:46 dolphin: time for dim patch?
09:52 lumag: mlankhorst, :-(
09:53 lumag: dolphin, yes, seems so. Like forbid dim push to -next-fixes if the baseline is an RC kernel?
09:54 dolphin: yeah, something along those lines
09:55 lumag: mlankhorst, hmm, why are these patches being committed to -fixes at all? they don't have Fixes tag, the CONFIG_DEBUG_FS doesn't seem to have real author's name.
10:05 mlankhorst: dliviu: ^
10:07 mlankhorst: dliviu: Can you please commit fixes to drm-misc-fixes if they apply there? I think in this case, the most recent patch you committed there should be in drm-misc-next not next-fixes unless it fixed a compilation failure.
10:09 mlankhorst: And even then, only during merge windows if it doesn't apply on drm-misc-fixes. :)
10:28 dliviu: mlankhorst: appologies, for some braindead reason I've made my mind that fixes that don't need to go in this cycle go into drm-misc-next-fixes
10:30 dliviu: I was also hoping (expecting) that drm-misc-fixes was already at -rc1 or -rc2, although I didn't check
10:32 dliviu: mlankhorst: "unless it fixed a compilation failure". I'm guessing you mean that next-fixes is only meant to fix integration in linux-next at this moment, and not collecting patches that could go as fixes into drm-misc-next, right?
10:32 kode54: should I report this panic on the amd drm tracker? or a different tracker? and what shall I title the issue?
10:32 kode54: https://0x0.st/XcQU.log.txt
10:39 mlankhorst: dliviu: Correct. :)
10:40 mlankhorst: If it breaks stable, it goes to drm-misc-fixes.
10:49 kode54: should I be asking #radeon about my panic instead? I think I should have asked there in the first place
11:55 tzimmermann: what's the semantics of gem.vmap ref-counting? in some drivers, drm_gem_vmap() does ref-count the returned mapping; in some not.
11:55 pinchartl: is it me, or does the DRM dumb GEM buffer helpers fail to enforce usage of MAP_SHARED (which translates to VM_SHARED) when mmap()ing the buffers ? it looks like we always implement MAP_SHARED semantics, even if MAP_PRIVATE is used
12:24 cascardo: hey, folks, would anyone be able to take a look at: https://lore.kernel.org/dri-devel/20240324101533.3271056-1-cascardo@igalia.com/T/#u ?
13:01 MrCooper: karolherbst: any idea how 5db73986725027b3b42e05fb4cf863ed21b0b81f could have broken piglit cl-custom-buffer-flags with rusticl on radeonsi? That's where git bisect landed, and it seems consistent
13:09 karolherbst: MrCooper: Probably the "unsigned compression_rate:4;" addition somehow
13:09 karolherbst: but I don't really see how
13:10 karolherbst: could be some bindgen related bug
13:10 karolherbst: MrCooper: what's breaking anyway?
13:11 MrCooper: some of the sub-tests get seemingly random results
13:12 pq: It's the first field ever with a size less than a byte?
13:13 karolherbst: maybe I should just run mesa/main on my test machine and see what breaks
13:13 MrCooper: yeah, curious if you see the same
13:14 karolherbst: could also trigger some UB it didn't before
13:58 Company: pq: just to confirm I got my analysis right: using GL_SRGB isn't correct with premultiplied alpha, because premultiplication should happen after the linear->srgb conversion, and with GL_SRGB it's the other way around?
13:58 Company: which means when an app wants to do linear compositing on Wayland - and the app has transparency - it can't use GL_SRGB
14:03 karolherbst: MrCooper: funny.. it's only regressing radeonsi...
14:03 MrCooper: heh
14:30 karolherbst: MrCooper: yeah... so pipe_resource.usage changes...
14:30 karolherbst: uhhhhh
14:31 karolherbst: bindgen writes usage at +64, not +60
14:32 daniels: what happens if you either make compression_rate be :8, or add unsigned unused:4 after it?
14:32 karolherbst: I'm sure either solution fixes it
14:32 karolherbst: I'm more interested what happens once usage is :9
14:36 karolherbst: yeah, so either works
14:59 karolherbst: anyway, I'm kinda have a headache, so I'm dealing with it tomorrow I guess
14:59 karolherbst: or maybe one of you submits an MR to workaround it
14:59 karolherbst: but I think it's an upstream bindgen bug
15:22 MrCooper: karolherbst: thanks for looking into it, get better soon
15:38 FireBurn: Hey, I've been seeing weird ghosting arifacts of Chromium under Kwin (pure wayland) and I'm not sure if it's a Kwin bug or a radeonsi / amdgpu bug
15:38 FireBurn: Here's the bug link https://bugs.kde.org/show_bug.cgi?id=488454
17:17 pastehearted: technically adder is also easy, in compact format, but subtract is even easier, though you might had already realized that it's not me who is delusional if those people who diagnosed me were only scammers, things would not been dangerous to me, cause at the end of the day, people believe what they want, they were life threatening terrorists too what I said, that's why it hurts to listen
17:17 pastehearted: what they say and hurts to see what bad they commit in life, delusions are big but everyone understood whom to tap, me I have the capabilities and organs to deal with things in highest end programming that is manual intervention, but if I was over too rude to you, and it turns out that it was unneeded or you never earned such treatment, cause I spotted that the legal trouble and abuse to
17:17 pastehearted: finish me comes from western world, like all scars on my body was ordered from various western instances, but if it was none of you, I definitely can give access to all the explanations and slides how things really work, already now, cause the creation of those goes pretty quick.
19:38 karolherbst: MrCooper: we should add a pad:4 thing so that usage gets properly aligned anyway.. atm it's touching 2 bytes, so I think to have more optimal code we should do something about it anyway
20:13 karolherbst: MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29720
21:56 Hazematman: How can I ensure that an MR gets included in the next mesa 24.1.x release? There are a couple issues (#11257, #11321, #11332) that I suspect are all the same problem and should be fixed by !29546. All these issues have users using a mesa 24.1.0 release, so it would be nice if this fix made into the next bug fix release to prevent their systems from crashing
21:57 jenatali: Add Cc: mesa-stable to the commit message, or even better is Fixes: <sha> ("commit title")
21:58 Hazematman: jenatali: The MR is already merged, is there something else I need to do?
21:59 jenatali: Oh, in that case you can cherry-pick and send a new PR against the staging/24.1 branch
21:59 pendingchaos: Hazematman: https://docs.mesa3d.org/submittingpatches.html#sending-backports-for-the-stable-branch
21:59 jenatali: Er, MR
21:59 Hazematman: Thanks!
22:58 haagch: Î tried adding the microsoft non-desktop edid flag https://github.com/OSVR/OSVR-HDK-MCU-Firmware/blob/fef00a34aa36d7122c61c37e0d37a68d1ce67f22/Source%20code/Embedded/src/Variants/HDK_20_SVR/edid.json#L164-L188 to an edid, then `cat edid.data > /sys/kernel/debug/dri/1/DP-2/edid_override` and `echo 1 > /sys/kernel/debug/dri/1/DP-2/trigger_hotplug`
22:59 haagch: I see my modified edid in /sys/class/drm/card1-DP-2/edid but on kwin_wayland it doesn't look like the non-desktop flag is applied, e.g. (with xwayland) xrandr --prop shows non-desktop: 0
23:00 haagch: the kernel parses this edid flag here https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/217a8c63df30246f180760b1e1f3e57267efbb6a. so would that be supposed to work with a debugfs edid override?
23:01 haagch: (also is there a way to remove the edid override without rebooting?)