05:41 Kayden: might need some marge help on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42464 ... we're on try #5 now, the latest of which had a 9 hour wait
05:41 Kayden: one of the runs seems like it needed freedreno trace checksums updated, minorly, but I ran the script and it didn't update or do anything AFAICT
05:41 Kayden: and the subsequent run just died entirely on freedreno CI
05:42 Kayden: well, mostly a530, with some a306...half of them were ok
05:43 Kayden: but looks more like script/lab failures than actual failures
07:37 MrCooper: do I understand correctly that a DRM master which doesn't set DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE currently can't disable the color pipeline on planes?
07:44 emersion: yeah
07:44 emersion: same applies to other props, e.g. non-atomic KMS client not being able to reset atomic props, or virtual cursor props, etc
08:04 MrCooper: a default state mechanism can't come soon enough :)
08:09 emersion: for sure
08:50 MrCooper: oeuaoeuoeu[m] said on #wayland the color pipeline is supposed to be implicitly disabled on any commit by a DRM master which didn't set DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
09:15 valentine: Kayden: sorry about that, the Marge backlog never cleared up since yesterday and the freedreno devices went offline due to gitlab registry issue, but I have an idea to avoid that in the future
12:13 alyssa: hakzsam: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42743 looks like it needs traces updated?
12:14 hakzsam: missed that, thanks
14:47 tzimmermann: hi! i'd like to trade reviews for https://lore.kernel.org/dri-devel/20260702145021.226932-1-tzimmermann@suse.de/
16:10 mripard: MrCooper: emersion: your wish has been granted :)
16:11 mripard: https://lore.kernel.org/dri-devel/20260708-drm-reset-state-flag-v1-0-c37dc985485d@kernel.org/
16:12 MrCooper: whee, thanks
16:13 FireBurn: Does anyone on the list have a USB analyser by any chance?
16:13 mripard: we were discussing it yesterday with swick and jfalempe
16:16 MrCooper: mripard: "relies on all drivers implementing the atomic_create_state hook", unfortunately there's a popular out-of-tree driver, so this can't be enforced in the kernel
16:16 MrCooper: maybe add a cap for the flag, which depends on atomic_create_state?
16:17 mripard: it's not really about enforcement, it's that it's the only mechanism which allows us to do it
16:17 MrCooper: the point is the kernel can't rely on it
16:18 mripard: the plan is to have it mandatory when the roll-out is done
16:19 mripard: and if I need to fix/talk to people in charge of an out-of-tree driver to make it happen, I'm fine with that
16:19 MrCooper: a cap seems necessary for user space to know when it can use the flag anyway
16:22 MrCooper: making it conditional on the atomic_create_state hook being there seems straightforward
16:23 mripard: I'm still not quite sure what would be the point of adding a condition that would always be true, but sure, we can do that
16:24 MrCooper: it most likely won't always be true with that driver
16:25 emersion: mripard: oh wow, thanks! will have a look :)
16:29 tzimmermann: thanks, mripard
17:46 Kayden: valentine: thank you so much for the help!
21:45 airlied: glehmann: okay I'm giving in, I'll start looking at vtn types :-)