06:30wens: are drm/exynos patches merged through drm-misc or a separate tree? I see two entries in the MAINTAINERS file.
06:37airlied: usually the exynos tree
06:46wens: I see, the double entry was a bit confusing
07:26MrCooper: kusma: your "Open Source and AI" blog post expresses my thoughts on the subject better than I could have myself, thanks!
07:43pq: zmike, thank you very much for fixing the llvmpipe LastFragData!
08:54mripard: airlied: sima: mlankhorst: tzimmermann: any opinion on https://lore.kernel.org/r/20260326-drm-drm-atomic-update-v1-0-2f7af5f4ad02@kernel.org ?
08:57tzimmermann: mripard, well, ok
08:57tzimmermann: mripard, the canonical name would be transaction
08:58mripard: that's what sima suggested
08:58tzimmermann: although that might over-sell it a bit
08:58mripard: but the todo was "commit" :)
08:58mripard: so I took the middle road ignored both equally :p
08:58mripard: I'm ok with transaction too
08:58tzimmermann: :D
08:59sima: same, either is a massive improvement over the current situation
08:59tzimmermann: the thing with transaction is that is doesn't really say what transaction. would that be clear from the context of drm?
08:59sima: also historically drm_atomic_state was just a state and used clever tricks to make it a commit
09:00sima: turned out the tricks where too clever and explicit old/new states so much better design
09:00sima:did a little mistake
09:00sima: tzimmermann, hm yeah I think commit is a bit more established within the context of kms than transaction
09:00sima: either way, a-b: me
09:01tzimmermann: there is an atomic_update callback already. having drm_atomic_update seems misleading
09:01mripard: I'm fine with commit as well, but is there a concern with drm_crtc_commit?
09:01tzimmermann: how about "struct drm_state_update" ?
09:02tzimmermann: mripard, its not just 'crtc'
09:02sima: mripard, that one is also about tracking an atomic commit, so I think that's actually bonus for consistency
09:03sima: I've added drm_crtc_commit so that a generic nonblocking helper implementation is possible
09:03mripard: ok, so we all agree to use drm_atomic_commit then?
09:03tzimmermann: i can live with that
09:03mripard: awesome
09:03sima: not entirely awake, maybe collect a few more acks from big driver kms people
09:04tzimmermann: a-b: me
09:04sima: but yeah, sounds like the most fitting
09:04sima: but I'm a-b: me on any of transaction/commit/update really, all better than the current one
09:04mripard: I know pinchartl had opinions too :)
09:04mripard: and I'll send a new version with drm_atomic_commit anyway, we can gather a-b there
09:04sima: for merging probably best if airlied pushes it onto drm-next after -rc6/7 when all the big -next pr have landed
09:05sima: that's probably the least painful point
09:05sima: mripard, aye
09:05mripard: that was my next question
09:05mripard: sounds good to me
09:05mripard: I'll send it today
09:05mripard: thanks :)
09:05sima: mripard, yeah don't have a better idea, but also good excuse to get acks from the other subtrees (msm, intel-display, amd) so they're at the ready for the asap backmerge
09:28pinchartl: mripard: apparently I have opinions on everything :-)
09:29pinchartl: I think I have a slight preference for commit, as it matches the UAPI naming
09:29pinchartl: but I won't bikeshed much
09:36tzimmermann: PSA: With -rc6 tagged, drm-misc-next-fixes is now open. Features still go into drm-misc-next. Fixes for v6.19 or stable go into drm-misc-fixes. Fixes for v7.0 go into drm-misc-next-fixes. Patches in -fixes branches should be small and have a Fixes tag.
12:12zmike: pq: 🤝
13:06MrCooper: pq: I'm thinking more and more that the "max bpc" property really isn't suitable for the stated use case (RGB vs YCbCr), instead what's really needed there is a property to explicitly control the bpc?
13:08MrCooper: no need to guess what the intent was for setting "max bpc" to a given value then
13:13pq: MrCooper, I've been ignoring 'max bpc' because it's completely unrelated.
13:14MrCooper: it's currently required for the stated use case
13:14daniels: well, it's part of it
13:14pq: it is programmed IIRC, but not required
13:14MrCooper: there's no other way to control bpc
13:14pq: there is no need to control bpc for this use case
13:15daniels: the usecase isn't specifically to log a warning - the usecase is to enable control UI to be able to have a feedback loop and take better decisions on resolution / refresh rate / colour model
13:15pq: daniels, weston cannot do anything but log, though.
13:15MrCooper: and it logs only if the user sets a value for "max bpc"
13:16daniels: i.e. if you can hit 4k60 with no subsampling only by cutting down to 6bpc, the user (or media playback control) may decide that it would be better as a matter of policy to try 4k60+YUV422 to see if it will look less terrible, and if it still doesn't get any joy out of that, to pull down to 1080p
13:17daniels: there's no universally-correct answer, hence why the kernel can't 'dtrt' - but if userspace has no idea what the kernel is even doing, it's impossible for userspace to tell the kernel what the right thing would actually be
13:17pq: MrCooper, if you read my comments in the Weston MR, I have asked to not use max_bpc for that but add a new "desired bpc" settings.
13:18MrCooper: then we agree on that; trying to (ab)use "max bpc" for something it's not intended for is something that bothers me about this
13:18pq: yes!
13:18daniels:shrugs
13:19MrCooper: that would also largely side-step the issues we've been discussing — either the kernel can make the requested bpc work, or the atomic commit fails
13:19daniels: I agree that max bpc is not what we'd ideally have as the sole control mechanism; otoh it's hard to say that we shouldn't have a feedback mechanism for the control mechanism that we do actually have upstream, and that it can only come with a control mechanism which can express quite a few different orthogonal things
13:22MrCooper: the thing that bothers me the most is that the weston MR implies the "link bpc" value is expected to match the "max bpc" one
13:22pq: daniels, there is nothing to argue anymore. The Weston MR just needs the changes I suggested ages ago.